From: Thomas Zimmermann <tzimmermann@suse.de>
To: Javier Martinez Canillas <javierm@redhat.com>,
linux-kernel@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration
Date: Wed, 11 May 2022 14:05:57 +0200 [thread overview]
Message-ID: <8ec8d896-599e-b1ff-2b4f-077d73944705@suse.de> (raw)
In-Reply-To: <7d9f44e6-ae45-1747-366a-15cf2941dc2f@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]
Hi
Am 11.05.22 um 14:01 schrieb Javier Martinez Canillas:
> Hello Thomas,
>
> On 5/11/22 13:54, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:
>>> These can be used by subsystems to unregister a platform device registered
>>> by sysfb and also to disable future platform device registration in sysfb.
>>>
>>
>> I find it very hard to review these patches, as related things are put
>> into separate patches.
>>
>> I suggest to put the sysfb_disable() stuff into patch 5 and the rest
>> into patch 4.
>>
>
> Ok, you then want in the same patch to have both the helper definition
> and first usage.
>
> Other subsystems ask you to do the opposite, to split the definition and
> usage in separate patches. But I'm fine with merging those if you prefer.
Usually, I have no strong opinion on this. But in the case of this
specific patchset, I have the feeling that I'm missing some important
point because call and implementation are separate. See my other
replies for that. Putting them next to each other will hopefully help.
Sorry for the inconvenience.
Best regards
Thomas
>
>> Best regards
>> Thomas
>>
>>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2022-05-11 12:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-11 11:24 [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe Javier Martinez Canillas
2022-05-11 11:24 ` [PATCH v5 1/7] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer Javier Martinez Canillas
2022-05-11 12:04 ` Javier Martinez Canillas
2022-05-11 11:24 ` [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration Javier Martinez Canillas
2022-05-11 11:54 ` Thomas Zimmermann
2022-05-11 12:01 ` Javier Martinez Canillas
2022-05-11 12:05 ` Thomas Zimmermann [this message]
2022-05-11 12:29 ` Javier Martinez Canillas
2022-05-11 12:02 ` Thomas Zimmermann
2022-05-11 12:24 ` Javier Martinez Canillas
2022-05-11 11:30 ` [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices Javier Martinez Canillas
2022-05-11 11:47 ` Thomas Zimmermann
2022-05-11 11:57 ` Javier Martinez Canillas
2022-05-13 12:28 ` Javier Martinez Canillas
2022-05-11 11:31 ` [PATCH v5 4/7] fbdev: Make sysfb to unregister its own registered devices Javier Martinez Canillas
2022-05-11 11:31 ` [PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs Javier Martinez Canillas
2022-06-07 15:01 ` Daniel Vetter
2022-06-07 15:41 ` Javier Martinez Canillas
2022-05-11 11:32 ` [PATCH v5 6/7] Revert "fbdev: Prevent probing generic drivers if a FB is already registered" Javier Martinez Canillas
2022-05-11 11:32 ` [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c Javier Martinez Canillas
2022-05-11 17:00 ` Sam Ravnborg
2022-05-11 17:17 ` Guenter Roeck
2022-05-11 17:34 ` Javier Martinez Canillas
2022-05-12 18:32 ` Sam Ravnborg
2022-05-13 10:48 ` [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe Thomas Zimmermann
2022-05-13 11:10 ` Javier Martinez Canillas
2022-05-13 11:32 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ec8d896-599e-b1ff-2b4f-077d73944705@suse.de \
--to=tzimmermann@suse.de \
--cc=corbet@lwn.net \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=javierm@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).