linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org, Helge Deller <deller@gmx.de>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs
Date: Tue, 7 Jun 2022 17:41:08 +0200	[thread overview]
Message-ID: <da991c8e-bd19-d243-5433-82b9621df4aa@redhat.com> (raw)
In-Reply-To: <Yp9oLJ/HD2rHxO3z@phenom.ffwll.local>

Hello Daniel,

On 6/7/22 17:01, Daniel Vetter wrote:

[snip]

>>
>>  drivers/video/fbdev/core/fbmem.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index 9b035ef4d552..265efa189bcc 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1789,6 +1789,17 @@ int remove_conflicting_framebuffers(struct apertures_struct *a,
>>  	if (do_free)
>>  		kfree(a);
>>  
>> +	/*
>> +	 * If a driver asked to unregister a platform device registered by
>> +	 * sysfb, then can be assumed that this is a driver for a display
>> +	 * that is set up by the system firmware and has a generic driver.
>> +	 *
>> +	 * Drivers for devices that don't have a generic driver will never
>> +	 * ask for this, so let's assume that a real driver for the display
>> +	 * was already probed and prevent sysfb to register devices later.
>> +	 */
>> +	sysfb_disable();
> 
> So the og version had (or should have had at least) the sysfb_disable()
> call before we go through the loop and try to unregister stuff. I think
> this needs to be done before we call do_remove_conflicting_framebuffer()
> instead. With that:
>

Yes, the original version did that but also the original version didn't
attempt to remove the devices registered by sysfb on sysfb_disable().

I was going to answer that this has to be done after the loop because
that way fbmem could first ask sysfb to remove the devices, but then I
realized that you are correct That this wouldn't be needed if sysfb does
the disable (and unregistration) before the loop.

So by doing it before the loop, we should be able to drop [PATCH v5 4/7]
fbdev: Make sysfb to unregister its own registered devices:

https://lists.freedesktop.org/archives/dri-devel/2022-May/355201.html

Since by the time the loop is executed, no registered_fb associated with
a device that was registered by sysfb should be present in that array.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat


  reply	other threads:[~2022-06-07 15:41 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
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 [this message]
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=da991c8e-bd19-d243-5433-82b9621df4aa@redhat.com \
    --to=javierm@redhat.com \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tzimmermann@suse.de \
    /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).