All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	robh+dt@kernel.org, frowand.list@gmail.com, daniel@ffwll.ch,
	deller@gmx.de, sam@ravnborg.org, linux@roeck-us.net,
	mpe@ellerman.id.au, benh@kernel.crashing.org, paulus@samba.org,
	devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] fbdev: Remove hot-unplug workaround for framebuffers without device
Date: Wed, 13 Apr 2022 18:05:51 +0200	[thread overview]
Message-ID: <Ylb0316ABOhOe1Rb@phenom.ffwll.local> (raw)
In-Reply-To: <2e183cc9-603d-f038-54aa-5601f11b0484@redhat.com>

On Wed, Apr 13, 2022 at 12:50:50PM +0200, Javier Martinez Canillas wrote:
> On 4/13/22 11:24, Thomas Zimmermann wrote:
> > A workaround makes fbdev hot-unplugging work for framebuffers without
> > device. The only user for this feature was offb. As each OF framebuffer
> > now has an associated platform device, the workaround is no longer
> > needed. Remove it. Effectively reverts commit 0f525289ff0d ("fbdev: Fix
> > unregistering of framebuffers without device").
> > 
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> >  drivers/video/fbdev/core/fbmem.c | 9 +--------
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index bc6ed750e915..bdd00d381bbc 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1579,14 +1579,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> >  			 * If it's not a platform device, at least print a warning. A
> >  			 * fix would add code to remove the device from the system.
> >  			 */
> > -			if (!device) {
> > -				/* TODO: Represent each OF framebuffer as its own
> > -				 * device in the device hierarchy. For now, offb
> > -				 * doesn't have such a device, so unregister the
> > -				 * framebuffer as before without warning.
> > -				 */
> > -				do_unregister_framebuffer(registered_fb[i]);
> 
> Maybe we could still keep this for a couple of releases but with a big
> warning that's not supported in case there are out-of-tree drivers out
> there that still do this ?
> 
> Or at least a warning if the do_unregister_framebuffer() call is removed.

Yeah dying while holding console_lock isn't fun, and not having a WARN_ON
+ bail-out code pretty much forces bug reporters to do a bisect here to
give us something more than "machine dies at boot with no messages".

I'd just outright keep the WARN_ON here for 1-2 years even to really make
sure we got all the bug reports, since often these older machines only
update onto LTS releases.

And it needs to be a WARN_ON + bail out since BUG_ON is as bad as just
oopsing.
-Daniel

> 
> Regardless of what you chose to do, the patch looks good to me.
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 
> -- 
> Best regards,
> 
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	frowand.list@gmail.com, deller@gmx.de,
	linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
	robh+dt@kernel.org, paulus@samba.org, mpe@ellerman.id.au,
	sam@ravnborg.org, linux@roeck-us.net
Subject: Re: [PATCH 2/2] fbdev: Remove hot-unplug workaround for framebuffers without device
Date: Wed, 13 Apr 2022 18:05:51 +0200	[thread overview]
Message-ID: <Ylb0316ABOhOe1Rb@phenom.ffwll.local> (raw)
In-Reply-To: <2e183cc9-603d-f038-54aa-5601f11b0484@redhat.com>

On Wed, Apr 13, 2022 at 12:50:50PM +0200, Javier Martinez Canillas wrote:
> On 4/13/22 11:24, Thomas Zimmermann wrote:
> > A workaround makes fbdev hot-unplugging work for framebuffers without
> > device. The only user for this feature was offb. As each OF framebuffer
> > now has an associated platform device, the workaround is no longer
> > needed. Remove it. Effectively reverts commit 0f525289ff0d ("fbdev: Fix
> > unregistering of framebuffers without device").
> > 
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> >  drivers/video/fbdev/core/fbmem.c | 9 +--------
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index bc6ed750e915..bdd00d381bbc 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1579,14 +1579,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> >  			 * If it's not a platform device, at least print a warning. A
> >  			 * fix would add code to remove the device from the system.
> >  			 */
> > -			if (!device) {
> > -				/* TODO: Represent each OF framebuffer as its own
> > -				 * device in the device hierarchy. For now, offb
> > -				 * doesn't have such a device, so unregister the
> > -				 * framebuffer as before without warning.
> > -				 */
> > -				do_unregister_framebuffer(registered_fb[i]);
> 
> Maybe we could still keep this for a couple of releases but with a big
> warning that's not supported in case there are out-of-tree drivers out
> there that still do this ?
> 
> Or at least a warning if the do_unregister_framebuffer() call is removed.

Yeah dying while holding console_lock isn't fun, and not having a WARN_ON
+ bail-out code pretty much forces bug reporters to do a bisect here to
give us something more than "machine dies at boot with no messages".

I'd just outright keep the WARN_ON here for 1-2 years even to really make
sure we got all the bug reports, since often these older machines only
update onto LTS releases.

And it needs to be a WARN_ON + bail out since BUG_ON is as bad as just
oopsing.
-Daniel

> 
> Regardless of what you chose to do, the patch looks good to me.
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 
> -- 
> Best regards,
> 
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	frowand.list@gmail.com, deller@gmx.de,
	linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org,
	robh+dt@kernel.org, paulus@samba.org, daniel@ffwll.ch,
	sam@ravnborg.org, linux@roeck-us.net
Subject: Re: [PATCH 2/2] fbdev: Remove hot-unplug workaround for framebuffers without device
Date: Wed, 13 Apr 2022 18:05:51 +0200	[thread overview]
Message-ID: <Ylb0316ABOhOe1Rb@phenom.ffwll.local> (raw)
In-Reply-To: <2e183cc9-603d-f038-54aa-5601f11b0484@redhat.com>

On Wed, Apr 13, 2022 at 12:50:50PM +0200, Javier Martinez Canillas wrote:
> On 4/13/22 11:24, Thomas Zimmermann wrote:
> > A workaround makes fbdev hot-unplugging work for framebuffers without
> > device. The only user for this feature was offb. As each OF framebuffer
> > now has an associated platform device, the workaround is no longer
> > needed. Remove it. Effectively reverts commit 0f525289ff0d ("fbdev: Fix
> > unregistering of framebuffers without device").
> > 
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
> >  drivers/video/fbdev/core/fbmem.c | 9 +--------
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index bc6ed750e915..bdd00d381bbc 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1579,14 +1579,7 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> >  			 * If it's not a platform device, at least print a warning. A
> >  			 * fix would add code to remove the device from the system.
> >  			 */
> > -			if (!device) {
> > -				/* TODO: Represent each OF framebuffer as its own
> > -				 * device in the device hierarchy. For now, offb
> > -				 * doesn't have such a device, so unregister the
> > -				 * framebuffer as before without warning.
> > -				 */
> > -				do_unregister_framebuffer(registered_fb[i]);
> 
> Maybe we could still keep this for a couple of releases but with a big
> warning that's not supported in case there are out-of-tree drivers out
> there that still do this ?
> 
> Or at least a warning if the do_unregister_framebuffer() call is removed.

Yeah dying while holding console_lock isn't fun, and not having a WARN_ON
+ bail-out code pretty much forces bug reporters to do a bisect here to
give us something more than "machine dies at boot with no messages".

I'd just outright keep the WARN_ON here for 1-2 years even to really make
sure we got all the bug reports, since often these older machines only
update onto LTS releases.

And it needs to be a WARN_ON + bail out since BUG_ON is as bad as just
oopsing.
-Daniel

> 
> Regardless of what you chose to do, the patch looks good to me.
> 
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
> 
> -- 
> Best regards,
> 
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2022-04-13 16:05 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13  9:24 [PATCH 0/2] of: Register platform device for each framebuffer Thomas Zimmermann
2022-04-13  9:24 ` Thomas Zimmermann
2022-04-13  9:24 ` [PATCH 1/2] of: Create platform devices for OF framebuffers Thomas Zimmermann
2022-04-13  9:24   ` Thomas Zimmermann
2022-04-13 10:45   ` Javier Martinez Canillas
2022-04-13 10:49     ` Thomas Zimmermann
2022-04-13 12:51   ` Rob Herring
2022-04-13 12:51     ` Rob Herring
2022-04-13 12:51     ` Rob Herring
2022-04-13 17:58     ` Thomas Zimmermann
2022-04-13 17:58       ` Thomas Zimmermann
2022-04-13 17:58       ` Thomas Zimmermann
2022-04-13 18:02       ` Javier Martinez Canillas
2022-04-13 18:02         ` Javier Martinez Canillas
2022-04-13 18:02         ` Javier Martinez Canillas
2022-04-13 18:46       ` Rob Herring
2022-04-13 18:46         ` Rob Herring
2022-04-13 18:46         ` Rob Herring
2022-04-13 18:53         ` Rob Herring
2022-04-13 18:53           ` Rob Herring
2022-04-13 18:53           ` Rob Herring
2022-04-18 18:09     ` Thomas Zimmermann
2022-04-18 18:09       ` Thomas Zimmermann
2022-04-18 18:09       ` Thomas Zimmermann
2022-04-13  9:24 ` [PATCH 2/2] fbdev: Remove hot-unplug workaround for framebuffers without device Thomas Zimmermann
2022-04-13  9:24   ` Thomas Zimmermann
2022-04-13 10:50   ` Javier Martinez Canillas
2022-04-13 16:05     ` Daniel Vetter [this message]
2022-04-13 16:05       ` Daniel Vetter
2022-04-13 16:05       ` Daniel Vetter
2022-04-13 18:09       ` Thomas Zimmermann
2022-04-13 18:09         ` Thomas Zimmermann
2022-04-13 18:09         ` Thomas Zimmermann
2022-04-19  7:22         ` Javier Martinez Canillas
2022-04-19  7:22           ` Javier Martinez Canillas
2022-04-19  7:22           ` Javier Martinez Canillas

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=Ylb0316ABOhOe1Rb@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=benh@kernel.crashing.org \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=frowand.list@gmail.com \
    --cc=javierm@redhat.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.