From: Daniel Vetter <hidden> Date: 2022-02-08 22:34:13
Hi all,
Second round, mostly just compile fixed and some minor polish to commit
messages. Also MAINTAINERS patch and fbcon scrolling patches are out
because they landed already.
There's still a handful here that need review (and somehow intel-gfx-ci
just keeled over on this).
Cheers, Daniel
Daniel Vetter (19):
fbcon: delete a few unneeded forward decl
fbcon: Move fbcon_bmove(_rec) functions
fbcon: Introduce wrapper for console->fb_info lookup
fbcon: delete delayed loading code
fbdev/sysfs: Fix locking
fbcon: Use delayed work for cursor
fbcon: Replace FBCON_FLAGS_INIT with a boolean
fb: Delete fb_info->queue
fbcon: Extract fbcon_open/release helpers
fbcon: Ditch error handling for con2fb_release_oldinfo
fbcon: move more common code into fb_open()
fbcon: use lock_fb_info in fbcon_open/release
fbcon: Consistently protect deferred_takeover with console_lock()
fbcon: Move console_lock for register/unlink/unregister
fbcon: Move more code into fbcon_release
fbcon: untangle fbcon_exit
fbcon: Maintain a private array of fb_info
Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
fbdev: Make registered_fb[] private to fbmem.c
drivers/video/fbdev/core/fbcon.c | 692 ++++++++++++++---------------
drivers/video/fbdev/core/fbcon.h | 8 +-
drivers/video/fbdev/core/fbmem.c | 35 +-
drivers/video/fbdev/core/fbsysfs.c | 2 +
drivers/video/fbdev/efifb.c | 11 -
drivers/video/fbdev/simplefb.c | 11 -
include/linux/fb.h | 8 +-
7 files changed, 342 insertions(+), 425 deletions(-)
--
2.34.1
From: Daniel Vetter <hidden> Date: 2022-02-08 22:22:55
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
v2: Rebase on top of Helge's reverts.
Acked-by: Sam Ravnborg <redacted> (v1)
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> (v1)
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:23:01
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Du Cheng <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 85 +++++++++++++-------------------
drivers/video/fbdev/core/fbcon.h | 4 +-
2 files changed, 35 insertions(+), 54 deletions(-)
@@ -867,7 +855,7 @@ static int set_con2fb_map(int unit, int newidx, int user)logo_shown!=FBCON_LOGO_DONTSHOW);if(!found)-fbcon_add_cursor_timer(info);+fbcon_add_cursor_work(info);con2fb_map_boot[unit]=newidx;con2fb_init_display(vc,info,unit,show_logo);}
@@ -2132,14 +2122,14 @@ static int fbcon_switch(struct vc_data *vc)}if(old_info!=info)-fbcon_del_cursor_timer(old_info);+fbcon_del_cursor_work(old_info);}if(fbcon_is_inactive(vc,info)||ops->blank_state!=FB_BLANK_UNBLANK)-fbcon_del_cursor_timer(info);+fbcon_del_cursor_work(info);else-fbcon_add_cursor_timer(info);+fbcon_add_cursor_work(info);set_blitting_type(vc,info);ops->cursor_reset=1;
@@ -2247,9 +2237,9 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)if(mode_switch||fbcon_is_inactive(vc,info)||ops->blank_state!=FB_BLANK_UNBLANK)-fbcon_del_cursor_timer(info);+fbcon_del_cursor_work(info);else-fbcon_add_cursor_timer(info);+fbcon_add_cursor_work(info);return0;}
From: Daniel Vetter <hidden> Date: 2022-02-08 22:23:24
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <redacted>
Cc: Claudio Suarez <redacted>
---
drivers/video/fbdev/core/fbcon.c | 33 +++++++++++++-------------------
1 file changed, 13 insertions(+), 20 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:26:38
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected by console_lock (because fbcon just
doesn't bother with lock_fb_info() at all), and lock_fb_info
protecting anything is really just a neat lie. But that's a much
bigger fish to fry.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Qing Wang <redacted>
Cc: Sam Ravnborg <redacted>
---
drivers/video/fbdev/core/fbsysfs.c | 2 ++
1 file changed, 2 insertions(+)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:26:39
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 134 +++++++++++++++----------------
1 file changed, 65 insertions(+), 69 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:28:15
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <redacted>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <redacted>
Cc: Zheyu Ma <redacted>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zhen Lei <redacted>
Cc: Xiyu Yang <redacted>
---
drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
2 files changed, 29 insertions(+), 27 deletions(-)
@@ -1735,9 +1718,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED,&event);}#endif-console_lock();fbcon_fb_unregistered(fb_info);-console_unlock();/* this may free fb info */put_fb_info(fb_info);
From: Daniel Vetter <hidden> Date: 2022-02-08 22:29:35
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann [off-list ref]
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <redacted>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <redacted>
Cc: Hans de Goede <redacted>
Cc: Ilya Trukhanov <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Peter Jones <pjones@redhat.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/efifb.c | 11 -----------
drivers/video/fbdev/simplefb.c | 11 -----------
2 files changed, 22 deletions(-)
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)char*option=NULL;efi_memory_desc_tmd;-/*-*Genericdriversmustnotberegisteredifaframebufferexists.-*Ifanativedriverwasprobed,thedisplayhardwarewasalready-*takenandattemptingtousethesystemframebufferisdangerous.-*/-if(num_registered_fb>0){-dev_err(&dev->dev,-"efifb: a framebuffer is already registered\n");-return-EINVAL;-}-if(screen_info.orig_video_isVGA!=VIDEO_TYPE_EFI||pci_dev_disabled)return-ENODEV;
@@ -413,17 +413,6 @@ static int simplefb_probe(struct platform_device *pdev)structsimplefb_par*par;structresource*res,*mem;-/*-*Genericdriversmustnotberegisteredifaframebufferexists.-*Ifanativedriverwasprobed,thedisplayhardwarewasalready-*takenandattemptingtousethesystemframebufferisdangerous.-*/-if(num_registered_fb>0){-dev_err(&pdev->dev,-"simplefb: a framebuffer is already registered\n");-return-EINVAL;-}-if(fb_get_options("simplefb",NULL))return-ENODEV;
From: Daniel Vetter <hidden> Date: 2022-02-08 22:29:35
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can deadlock)
- That also means no point in clearing deferred_takeover, we are
unloading everything anyway.
- Finally rename fbcon_exit to fbcon_release_all and move it, since
that's what's it doing when being called from consw->con_deinit
through fbcon_deinit.
To answer a question from Sam just quoting my own reply:
We loose the call to fbcon_release_all() here [in fb_console_exit()].
We have part of the old fbcon_exit() above, but miss the release parts.
Ah yes that's the entire point of this change. The release_all in the
fbcon exit path was only needed when fbcon was a separate module
indepedent from core fb.ko. Which means it was possible to unload fbcon
while having fbdev drivers registered.
But since we've merged them that has become impossible, so by the time the
fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
left. And hence removing them is pointless.
v2: Explain the why better (Sam)
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <redacted>
Cc: Du Cheng <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
1 file changed, 32 insertions(+), 31 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:29:35
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Du Cheng <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
@@ -3244,8 +3247,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,pr_info("fbcon: Taking over console\n");dummycon_unregister_output_notifier(&fbcon_output_nb);-deferred_takeover=false;-logo_shown=FBCON_LOGO_DONTSHOW;/* We may get called in atomic context */schedule_work(&fbcon_deferred_takeover_work);
From: Daniel Vetter <hidden> Date: 2022-02-08 22:30:14
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.
Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info
Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <redacted>
Cc: Sam Ravnborg <redacted>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: William Kucharski <redacted>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zheyu Ma <redacted>
Cc: Zhen Lei <redacted>
Cc: Xiyu Yang <redacted>
---
drivers/video/fbdev/core/fbcon.c | 5 +++++
drivers/video/fbdev/core/fbmem.c | 4 ----
2 files changed, 5 insertions(+), 4 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:30:17
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter [off-list ref]
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Since I had to audit the entire fbcon load code I also spotted a wrong
function name in a comment in fbcon_startup(), which this patch also
fixes.
v2: Explain why we also fix the comment (Sam)
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:34:10
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock (especially all the global variables), so the minor changes in
ordering of setup/cleanup do not matter.
v2: Explain a bit better why this is all correct (Sam)
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
---
drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
1 file changed, 53 insertions(+), 54 deletions(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:34:11
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
Cc: Claudio Suarez <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 76 ++++++++++++++++++--------------
1 file changed, 44 insertions(+), 32 deletions(-)
@@ -110,6 +110,18 @@ static struct fbcon_display fb_display[MAX_NR_CONSOLES];staticsignedcharcon2fb_map[MAX_NR_CONSOLES];staticsignedcharcon2fb_map_boot[MAX_NR_CONSOLES];+staticstructfb_info*fbcon_info_from_console(intconsole)+{+WARN_CONSOLE_UNLOCKED();++/*+*Notethatonlycon2fb_mapisprotectedbytheconsolelock,+*registered_fbisprotectedbyaseparatemutex.Thislookupcan+*thereforerace.+*/+returnregistered_fb[con2fb_map[console]];+}+staticintlogo_lines;/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGOenums.*/
@@ -1269,7 +1281,7 @@ static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,staticvoidfbcon_putcs(structvc_data*vc,constunsignedshort*s,intcount,intypos,intxpos){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_display*p=&fb_display[vc->vc_num];structfbcon_ops*ops=info->fbcon_par;
@@ -1289,7 +1301,7 @@ static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)staticvoidfbcon_clear_margins(structvc_data*vc,intbottom_only){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_ops*ops=info->fbcon_par;if(!fbcon_is_inactive(vc,info))
@@ -1731,7 +1743,7 @@ static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,staticboolfbcon_scroll(structvc_data*vc,unsignedintt,unsignedintb,enumcon_scrolldir,unsignedintcount){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_display*p=&fb_display[vc->vc_num];intscroll_partial=info->flags&FBINFO_PARTIAL_PAN_OK;
@@ -2244,7 +2256,7 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)staticintfbcon_debug_enter(structvc_data*vc){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_ops*ops=info->fbcon_par;ops->save_graphics=ops->graphics;
@@ -2257,7 +2269,7 @@ static int fbcon_debug_enter(struct vc_data *vc)staticintfbcon_debug_leave(structvc_data*vc){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_ops*ops=info->fbcon_par;ops->graphics=ops->save_graphics;
@@ -2447,7 +2459,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,staticintfbcon_set_font(structvc_data*vc,structconsole_font*font,unsignedintflags){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);unsignedcharcount=font->charcount;intw=font->width;inth=font->height;
From: Daniel Vetter <hidden> Date: 2022-02-08 22:34:12
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo() failure
case was very strange: Callers updated con2fb_map to the new value
before calling this function, but upon error con2fb_acquire_newinfo
reset it to the old value. Since I removed the call to fbcon_release
anyway that strange error path was sticking out like a sore thumb,
hence I removed it. Which also allows us to remove the oldidx
parameter from that function.
v2: Explain what's going on with oldidx and error paths (Sam)
v3: Drop unused variable (0day)
Acked-by: Sam Ravnborg <redacted> (v2)
Cc: kernel test robot <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <redacted>
Cc: Du Cheng <redacted>
---
drivers/video/fbdev/core/fbcon.c | 75 +++++++++++++-------------------
1 file changed, 30 insertions(+), 45 deletions(-)
@@ -693,48 +703,31 @@ static int fbcon_open(struct fb_info *info)return-ENODEV;}-return0;-}+ops=kzalloc(sizeof(structfbcon_ops),GFP_KERNEL);+if(!ops){+fbcon_release(info);+return-ENOMEM;+}-staticvoidfbcon_release(structfb_info*info)-{-if(info->fbops->fb_release)-info->fbops->fb_release(info,0);+INIT_DELAYED_WORK(&ops->cursor_work,fb_flashcursor);+ops->info=info;+info->fbcon_par=ops;+ops->cur_blink_jiffies=HZ/5;-module_put(info->fbops->owner);+return0;}staticintcon2fb_acquire_newinfo(structvc_data*vc,structfb_info*info,-intunit,intoldidx)+intunit){-structfbcon_ops*ops=NULL;interr;err=fbcon_open(info);if(err)returnerr;-if(!err){-ops=kzalloc(sizeof(structfbcon_ops),GFP_KERNEL);-if(!ops)-err=-ENOMEM;--INIT_DELAYED_WORK(&ops->cursor_work,fb_flashcursor);-}--if(!err){-ops->cur_blink_jiffies=HZ/5;-ops->info=info;-info->fbcon_par=ops;--if(vc)-set_blitting_type(vc,info);-}--if(err){-con2fb_map[unit]=oldidx;-fbcon_release(info);-}+if(vc)+set_blitting_type(vc,info);returnerr;}
@@ -842,9 +835,11 @@ static int set_con2fb_map(int unit, int newidx, int user)found=search_fb_in_map(newidx);-con2fb_map[unit]=newidx;-if(!err&&!found)-err=con2fb_acquire_newinfo(vc,info,unit,oldidx);+if(!err&&!found){+err=con2fb_acquire_newinfo(vc,info,unit);+if(!err)+con2fb_map[unit]=newidx;+}/**Ifoldfbisnotmappedtoanyoftheconsoles,
@@ -1024,7 +1009,7 @@ static void fbcon_init(struct vc_data *vc, int init)return;if(!info->fbcon_par)-con2fb_acquire_newinfo(vc,info,vc->vc_num,-1);+con2fb_acquire_newinfo(vc,info,vc->vc_num);/* If we are not the first console on thisfb,copythefontfromthatconsole*/
From: Daniel Vetter <hidden> Date: 2022-02-08 22:34:12
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
v2: I typoed the config name (0day)
Cc: kernel test robot <redacted>
Cc: Jens Frederich <redacted>
Cc: Jon Nettleton <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <redacted>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Zhen Lei <redacted>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Xiyu Yang <redacted>
Cc: linux-fbdev@vger.kernel.org
Cc: Zheyu Ma <redacted>
Cc: Guenter Roeck <linux@roeck-us.net>
---
drivers/video/fbdev/core/fbmem.c | 8 ++++++--
include/linux/fb.h | 7 +++----
2 files changed, 9 insertions(+), 6 deletions(-)
@@ -825,7 +822,7 @@ static int set_con2fb_map(int unit, int newidx, int user)intoldidx=con2fb_map[unit];structfb_info*info=registered_fb[newidx];structfb_info*oldinfo=NULL;-intfound,err=0;+intfound,err=0,show_logo;WARN_CONSOLE_UNLOCKED();
@@ -854,18 +851,15 @@ static int set_con2fb_map(int unit, int newidx, int user)*fbconshouldreleaseit.*/if(!err&&oldinfo&&!search_fb_in_map(oldidx))-err=con2fb_release_oldinfo(vc,oldinfo,info,unit,oldidx,-found);+con2fb_release_oldinfo(vc,oldinfo,info);-if(!err){-intshow_logo=(fg_console==0&&!user&&-logo_shown!=FBCON_LOGO_DONTSHOW);+show_logo=(fg_console==0&&!user&&+logo_shown!=FBCON_LOGO_DONTSHOW);-if(!found)-fbcon_add_cursor_work(info);-con2fb_map_boot[unit]=newidx;-con2fb_init_display(vc,info,unit,show_logo);-}+if(!found)+fbcon_add_cursor_work(info);+con2fb_map_boot[unit]=newidx;+con2fb_init_display(vc,info,unit,show_logo);if(!search_fb_in_map(info_idx))info_idx=newidx;
@@ -2769,7 +2763,7 @@ static inline void fbcon_unbind(void) {}/* called with console_lock held */voidfbcon_fb_unbind(structfb_info*info){-inti,new_idx=-1,ret=0;+inti,new_idx=-1;intidx=info->node;WARN_CONSOLE_UNLOCKED();
From: Daniel Vetter <hidden> Date: 2022-02-08 22:37:04
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
From: Daniel Vetter <hidden> Date: 2022-02-08 22:39:28
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need to hold a full fb_info reference, which
is nice because doing so would mean a refcount loop between the
console and the fb_info. But it's also not nice since it means
console_lock() must be held absolutely everywhere. Well strictly
speaking we could still try to do some refcounting games again by
calling get_fb_info before we drop the console_lock. But things will
get tricky.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <redacted>
Cc: Du Cheng <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
1 file changed, 43 insertions(+), 39 deletions(-)
@@ -518,7 +516,7 @@ static int do_fbcon_takeover(int show_logo){interr,i;-if(!num_registered_fb)+if(!fbcon_num_registered_fb)return-ENODEV;if(!show_logo)
@@ -821,7 +819,7 @@ static int set_con2fb_map(int unit, int newidx, int user){structvc_data*vc=vc_cons[unit].d;intoldidx=con2fb_map[unit];-structfb_info*info=registered_fb[newidx];+structfb_info*info=fbcon_registered_fb[newidx];structfb_info*oldinfo=NULL;intfound,err=0,show_logo;
@@ -839,7 +837,7 @@ static int set_con2fb_map(int unit, int newidx, int user)}if(oldidx!=-1)-oldinfo=registered_fb[oldidx];+oldinfo=fbcon_registered_fb[oldidx];found=search_fb_in_map(newidx);
@@ -2098,9 +2096,9 @@ static int fbcon_switch(struct vc_data *vc)**info->currcon=vc->vc_num;*/-for_each_registered_fb(i){-if(registered_fb[i]->fbcon_par){-structfbcon_ops*o=registered_fb[i]->fbcon_par;+fbcon_for_each_registered_fb(i){+if(fbcon_registered_fb[i]->fbcon_par){+structfbcon_ops*o=fbcon_registered_fb[i]->fbcon_par;o->currcon=vc->vc_num;}
@@ -2745,7 +2743,7 @@ int fbcon_mode_deleted(struct fb_info *info,j=con2fb_map[i];if(j==-1)continue;-fb_info=registered_fb[j];+fb_info=fbcon_registered_fb[j];if(fb_info!=info)continue;p=&fb_display[i];
@@ -2801,7 +2799,7 @@ void fbcon_fb_unbind(struct fb_info *info)set_con2fb_map(i,new_idx,0);}}else{-structfb_info*info=registered_fb[idx];+structfb_info*info=fbcon_registered_fb[idx];/* This is sort of like set_con2fb_map, except it maps*theconsolestonodeviceandthenreleasesthe
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-02-08 23:06:37
On 2/8/22 22:08, Daniel Vetter wrote:
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vetter <redacted>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-02-08 23:59:30
Hello Daniel,
On 2/8/22 22:08, Daniel Vetter wrote:
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
Maybe also make it more explicit in the commit message that the delayed
work is replacing a timer that was used before for the cursor ?
The motiviation here is that fbcon code stops using the fb_info.queue,
motivation
[snip]
quoted hunk
/*
* This is the interface between the low-level console driver and the
@@ -68,7 +68,7 @@ struct fbcon_ops { int (*update_start)(struct fb_info *info); int (*rotate_font)(struct fb_info *info, struct vc_data *vc); struct fb_var_screeninfo var; /* copy of the current fb_var_screeninfo */- struct timer_list cursor_timer; /* Cursor timer */+ struct delayed_work cursor_work; /* Cursor timer */
A delayed_work uses a timer underneath but I wonder if the comment also
needs to be updated since technically isn't a timer anymore but deferred
work that gets re-scheduled each time on fb_flashcursor().
The patch looks good to me and makes the logic much simpler than before.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-02-09 00:19:36
On 2/8/22 22:08, Daniel Vetter wrote:
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann [off-list ref]
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
of platform devices matched with fbdev drivers to be properly unregistered if
a DRM driver attempts to remove all the conflicting framebuffers.
But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
a FB is already registered") worked around is different. It happens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't revert fb561bf9abde until that.
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:17:09
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
v2: Rebase on top of Helge's reverts.
Acked-by: Sam Ravnborg <redacted> (v1)
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> (v1)
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:17:46
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Avoids two forward declarations, and more importantly, matches what
I've done in my fbcon scrolling restore patches - so I need this to
avoid a bunch of conflicts in rebasing since we ended up merging
Helge's series instead.
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <redacted>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:18:58
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
Cc: Claudio Suarez <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
@@ -110,6 +110,18 @@ static struct fbcon_display fb_display[MAX_NR_CONSOLES];staticsignedcharcon2fb_map[MAX_NR_CONSOLES];staticsignedcharcon2fb_map_boot[MAX_NR_CONSOLES];+staticstructfb_info*fbcon_info_from_console(intconsole)+{+WARN_CONSOLE_UNLOCKED();++/*+*Notethatonlycon2fb_mapisprotectedbytheconsolelock,+*registered_fbisprotectedbyaseparatemutex.Thislookupcan+*thereforerace.+*/+returnregistered_fb[con2fb_map[console]];+}+staticintlogo_lines;/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGOenums.*/
@@ -1269,7 +1281,7 @@ static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,staticvoidfbcon_putcs(structvc_data*vc,constunsignedshort*s,intcount,intypos,intxpos){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_display*p=&fb_display[vc->vc_num];structfbcon_ops*ops=info->fbcon_par;
@@ -1289,7 +1301,7 @@ static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)staticvoidfbcon_clear_margins(structvc_data*vc,intbottom_only){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_ops*ops=info->fbcon_par;if(!fbcon_is_inactive(vc,info))
@@ -1731,7 +1743,7 @@ static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,staticboolfbcon_scroll(structvc_data*vc,unsignedintt,unsignedintb,enumcon_scrolldir,unsignedintcount){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_display*p=&fb_display[vc->vc_num];intscroll_partial=info->flags&FBINFO_PARTIAL_PAN_OK;
@@ -2244,7 +2256,7 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)staticintfbcon_debug_enter(structvc_data*vc){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_ops*ops=info->fbcon_par;ops->save_graphics=ops->graphics;
@@ -2257,7 +2269,7 @@ static int fbcon_debug_enter(struct vc_data *vc)staticintfbcon_debug_leave(structvc_data*vc){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);structfbcon_ops*ops=info->fbcon_par;ops->graphics=ops->save_graphics;
@@ -2447,7 +2459,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,staticintfbcon_set_font(structvc_data*vc,structconsole_font*font,unsignedintflags){-structfb_info*info=registered_fb[con2fb_map[vc->vc_num]];+structfb_info*info=fbcon_info_from_console(vc->vc_num);unsignedcharcount=font->charcount;intw=font->width;inth=font->height;
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:20:36
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter [off-list ref]
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Since I had to audit the entire fbcon load code I also spotted a wrong
function name in a comment in fbcon_startup(), which this patch also
fixes.
v2: Explain why we also fix the comment (Sam)
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:22:08
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected by console_lock (because fbcon just
doesn't bother with lock_fb_info() at all), and lock_fb_info
protecting anything is really just a neat lie. But that's a much
bigger fish to fry.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <redacted>
Cc: Qing Wang <redacted>
Cc: Sam Ravnborg <redacted>
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:38:10
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
quoted hunk
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Du Cheng <redacted>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 85 +++++++++++++-------------------
drivers/video/fbdev/core/fbcon.h | 4 +-
2 files changed, 35 insertions(+), 54 deletions(-)
There's similar code in fbcon_startup() when there should be a single
init function for fbcon_ops. Maybe something for later.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
@@ -867,7 +855,7 @@ static int set_con2fb_map(int unit, int newidx, int user) logo_shown != FBCON_LOGO_DONTSHOW); if (!found)- fbcon_add_cursor_timer(info);+ fbcon_add_cursor_work(info); con2fb_map_boot[unit] = newidx; con2fb_init_display(vc, info, unit, show_logo); }
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:38:57
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
It was only used by fbcon, and that now switched to its own,
private work.
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 11:46:37
Hi
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
quoted hunk
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock (especially all the global variables), so the minor changes in
ordering of setup/cleanup do not matter.
v2: Explain a bit better why this is all correct (Sam)
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
---
drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
1 file changed, 53 insertions(+), 54 deletions(-)
We don't need oldidx any longer?
There's some logic wrt to the parameter 'found' here and in
set_con2fb_map() that appears to be relevant.
Best regards
Thomas
quoted hunk
- if (!found && newinfo->fbops->fb_release)
- newinfo->fbops->fb_release(newinfo, 0);
- if (!found)
- module_put(newinfo->fbops->owner);
- err = -ENODEV;
- }
+ fbcon_release(oldinfo);
- if (!err) {
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
- module_put(oldinfo->fbops->owner);
- /*
- If oldinfo and newinfo are driving the same hardware,
- the fb_release() method of oldinfo may attempt to
- restore the hardware state. This will leave the
- newinfo in an undefined state. Thus, a call to
- fb_set_par() may be needed for the newinfo.
- */
- if (newinfo && newinfo->fbops->fb_set_par) {
- ret = newinfo->fbops->fb_set_par(newinfo);
+ fbcon_del_cursor_work(oldinfo);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(oldinfo->fbcon_par);
+ oldinfo->fbcon_par = NULL;
+ /*
+ If oldinfo and newinfo are driving the same hardware,
+ the fb_release() method of oldinfo may attempt to
+ restore the hardware state. This will leave the
+ newinfo in an undefined state. Thus, a call to
+ fb_set_par() may be needed for the newinfo.
+ */
+ if (newinfo && newinfo->fbops->fb_set_par) {
+ ret = newinfo->fbops->fb_set_par(newinfo);
- if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
- }
+ if (ret)
+ printk(KERN_ERR "con2fb_release_oldinfo: "
+ "detected unhandled fb_set_par error, "
+ "error code %d\n", ret);
}
- return err;
+ return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -825,7 +822,7 @@ static int set_con2fb_map(int unit, int newidx, int user)intoldidx=con2fb_map[unit];structfb_info*info=registered_fb[newidx];structfb_info*oldinfo=NULL;-intfound,err=0;+intfound,err=0,show_logo;WARN_CONSOLE_UNLOCKED();
@@ -854,18 +851,15 @@ static int set_con2fb_map(int unit, int newidx, int user)*fbconshouldreleaseit.*/if(!err&&oldinfo&&!search_fb_in_map(oldidx))-err=con2fb_release_oldinfo(vc,oldinfo,info,unit,oldidx,-found);+con2fb_release_oldinfo(vc,oldinfo,info);-if(!err){-intshow_logo=(fg_console==0&&!user&&-logo_shown!=FBCON_LOGO_DONTSHOW);+show_logo=(fg_console==0&&!user&&+logo_shown!=FBCON_LOGO_DONTSHOW);-if(!found)-fbcon_add_cursor_work(info);-con2fb_map_boot[unit]=newidx;-con2fb_init_display(vc,info,unit,show_logo);-}+if(!found)+fbcon_add_cursor_work(info);+con2fb_map_boot[unit]=newidx;+con2fb_init_display(vc,info,unit,show_logo);if(!search_fb_in_map(info_idx))info_idx=newidx;
@@ -2769,7 +2763,7 @@ static inline void fbcon_unbind(void) {}/* called with console_lock held */voidfbcon_fb_unbind(structfb_info*info){-inti,new_idx=-1,ret=0;+inti,new_idx=-1;intidx=info->node;WARN_CONSOLE_UNLOCKED();
From: Thomas Zimmermann <tzimmermann@suse.de> Date: 2022-02-10 14:16:55
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Note that the error handling for the con2fb_acquire_newinfo() failure
case was very strange: Callers updated con2fb_map to the new value
before calling this function, but upon error con2fb_acquire_newinfo
reset it to the old value. Since I removed the call to fbcon_release
anyway that strange error path was sticking out like a sore thumb,
hence I removed it. Which also allows us to remove the oldidx
parameter from that function.
v2: Explain what's going on with oldidx and error paths (Sam)
v3: Drop unused variable (0day)
Acked-by: Sam Ravnborg <redacted> (v2)
Cc: kernel test robot <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <redacted>
Cc: Du Cheng <redacted>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
That's the init function I was looking for, I guess.
@@ -693,48 +703,31 @@ static int fbcon_open(struct fb_info *info)return-ENODEV;}-return0;-}+ops=kzalloc(sizeof(structfbcon_ops),GFP_KERNEL);+if(!ops){+fbcon_release(info);+return-ENOMEM;+}-staticvoidfbcon_release(structfb_info*info)-{-if(info->fbops->fb_release)-info->fbops->fb_release(info,0);+INIT_DELAYED_WORK(&ops->cursor_work,fb_flashcursor);+ops->info=info;+info->fbcon_par=ops;+ops->cur_blink_jiffies=HZ/5;-module_put(info->fbops->owner);+return0;}staticintcon2fb_acquire_newinfo(structvc_data*vc,structfb_info*info,-intunit,intoldidx)+intunit){-structfbcon_ops*ops=NULL;interr;err=fbcon_open(info);if(err)returnerr;-if(!err){-ops=kzalloc(sizeof(structfbcon_ops),GFP_KERNEL);-if(!ops)-err=-ENOMEM;--INIT_DELAYED_WORK(&ops->cursor_work,fb_flashcursor);-}--if(!err){-ops->cur_blink_jiffies=HZ/5;-ops->info=info;-info->fbcon_par=ops;--if(vc)-set_blitting_type(vc,info);-}--if(err){-con2fb_map[unit]=oldidx;-fbcon_release(info);-}+if(vc)+set_blitting_type(vc,info);returnerr;}
@@ -842,9 +835,11 @@ static int set_con2fb_map(int unit, int newidx, int user)found=search_fb_in_map(newidx);-con2fb_map[unit]=newidx;-if(!err&&!found)-err=con2fb_acquire_newinfo(vc,info,unit,oldidx);+if(!err&&!found){+err=con2fb_acquire_newinfo(vc,info,unit);+if(!err)+con2fb_map[unit]=newidx;+}/**Ifoldfbisnotmappedtoanyoftheconsoles,
@@ -1024,7 +1009,7 @@ static void fbcon_init(struct vc_data *vc, int init)return;if(!info->fbcon_par)-con2fb_acquire_newinfo(vc,info,vc->vc_num,-1);+con2fb_acquire_newinfo(vc,info,vc->vc_num);/* If we are not the first console on thisfb,copythefontfromthatconsole*/
--
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
From: Daniel Vetter <hidden> Date: 2022-04-05 11:42:41
On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
quoted
On 2/8/22 22:08, Daniel Vetter wrote:
quoted
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann [off-list ref]
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
of platform devices matched with fbdev drivers to be properly unregistered if
a DRM driver attempts to remove all the conflicting framebuffers.
But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
a FB is already registered") worked around is different. It happens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't revert fb561bf9abde until that.
Yeah that entire area is a mess still, ideally we'd have something else
creating the platform devices, and efifb/offb and all these would just
bind against them.
Hm one idea that just crossed my mind: Could we have a flag in fb_info for
fw drivers, and check this in framebuffer_register? Then at least all the
logic would be in the fbdev core.
Ok coffee just kicked in, how exactly does your scenario work?
This code I'm reverting here is in the platform_dev->probe function.
Thomas' patch removes the platform_dev. How exactly can you still probe
against a platform dev if that platform dev is gone?
Iow, now that I reponder your case after a few weeks I'm no longer sure
things work like you claim.
There is the issue that offb still bidns without a platform_dev, but
that's not affected by this patch here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Daniel Vetter <hidden> Date: 2022-04-05 12:16:52
On Thu, Feb 10, 2022 at 12:46:32PM +0100, Thomas Zimmermann wrote:
Hi
Am 08.02.22 um 22:08 schrieb Daniel Vetter:
quoted
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Note that everything in fbcon.c is protected by the big console_lock()
lock (especially all the global variables), so the minor changes in
ordering of setup/cleanup do not matter.
v2: Explain a bit better why this is all correct (Sam)
Acked-by: Sam Ravnborg <redacted>
Signed-off-by: Daniel Vetter <redacted>
Cc: Daniel Vetter <redacted>
Cc: Claudio Suarez <redacted>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <redacted>
---
drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
1 file changed, 53 insertions(+), 54 deletions(-)
We don't need oldidx any longer?
There's some logic wrt to the parameter 'found' here and in set_con2fb_map()
that appears to be relevant.
Yeah further patches clean this up more. Or did you see a potential bug
here? I did ditch the fb_release error handling, simply because there's
not really much we can do anyway, it shouldn't ever fail (that's a driver
bug) and it was convoluting the code for no gain. But I might have missed
something in this cargo-cult.
-Daniel
Best regards
Thomas
quoted
- if (!found && newinfo->fbops->fb_release)
- newinfo->fbops->fb_release(newinfo, 0);
- if (!found)
- module_put(newinfo->fbops->owner);
- err = -ENODEV;
- }
+ fbcon_release(oldinfo);
- if (!err) {
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
- module_put(oldinfo->fbops->owner);
- /*
- If oldinfo and newinfo are driving the same hardware,
- the fb_release() method of oldinfo may attempt to
- restore the hardware state. This will leave the
- newinfo in an undefined state. Thus, a call to
- fb_set_par() may be needed for the newinfo.
- */
- if (newinfo && newinfo->fbops->fb_set_par) {
- ret = newinfo->fbops->fb_set_par(newinfo);
+ fbcon_del_cursor_work(oldinfo);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(oldinfo->fbcon_par);
+ oldinfo->fbcon_par = NULL;
+ /*
+ If oldinfo and newinfo are driving the same hardware,
+ the fb_release() method of oldinfo may attempt to
+ restore the hardware state. This will leave the
+ newinfo in an undefined state. Thus, a call to
+ fb_set_par() may be needed for the newinfo.
+ */
+ if (newinfo && newinfo->fbops->fb_set_par) {
+ ret = newinfo->fbops->fb_set_par(newinfo);
- if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
- }
+ if (ret)
+ printk(KERN_ERR "con2fb_release_oldinfo: "
+ "detected unhandled fb_set_par error, "
+ "error code %d\n", ret);
}
- return err;
+ return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
From: Daniel Vetter <hidden> Date: 2022-04-05 12:35:12
On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
On 2/8/22 22:08, Daniel Vetter wrote:
quoted
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann [off-list ref]
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
of platform devices matched with fbdev drivers to be properly unregistered if
a DRM driver attempts to remove all the conflicting framebuffers.
But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
a FB is already registered") worked around is different. It happens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't revert fb561bf9abde until that.
Yeah that entire area is a mess still, ideally we'd have something else
creating the platform devices, and efifb/offb and all these would just
bind against them.
Hm one idea that just crossed my mind: Could we have a flag in fb_info for
fw drivers, and check this in framebuffer_register? Then at least all the
logic would be in the fbdev core.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-04-05 14:21:00
Hello Daniel,
On 4/5/22 10:40, Daniel Vetter wrote:
On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
quoted
On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
quoted
On 2/8/22 22:08, Daniel Vetter wrote:
quoted
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann [off-list ref]
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
of platform devices matched with fbdev drivers to be properly unregistered if
a DRM driver attempts to remove all the conflicting framebuffers.
But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
a FB is already registered") worked around is different. It happens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't revert fb561bf9abde until that.
Yeah that entire area is a mess still, ideally we'd have something else
creating the platform devices, and efifb/offb and all these would just
bind against them.
Hm one idea that just crossed my mind: Could we have a flag in fb_info for
fw drivers, and check this in framebuffer_register? Then at least all the
logic would be in the fbdev core.
I can't answer right away since I've since forgotten this part of the code
and will require to do a detailed read to refresh my memory.
I'll answer later but preferred to mention the other question ASAP.
Ok coffee just kicked in, how exactly does your scenario work?
This code I'm reverting here is in the platform_dev->probe function.
Thomas' patch removes the platform_dev. How exactly can you still probe
against a platform dev if that platform dev is gone?
Because the platform was not even registered by the time the DRM driver
probed and all the devices for the conflicting drivers were unregistered.
Iow, now that I reponder your case after a few weeks I'm no longer sure
things work like you claim.
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Daniel Vetter <hidden> Date: 2022-04-05 14:40:13
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
[off-list ref] wrote:
Hello Daniel,
On 4/5/22 10:40, Daniel Vetter wrote:
quoted
On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
quoted
On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
quoted
On 2/8/22 22:08, Daniel Vetter wrote:
quoted
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann [off-list ref]
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
of platform devices matched with fbdev drivers to be properly unregistered if
a DRM driver attempts to remove all the conflicting framebuffers.
But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
a FB is already registered") worked around is different. It happens when the
DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
kicking out of conflicting framebuffers already happened and these drivers
will be allowed to probe even when a DRM driver is already present.
We need a clearer way to prevent it, but can't revert fb561bf9abde until that.
Yeah that entire area is a mess still, ideally we'd have something else
creating the platform devices, and efifb/offb and all these would just
bind against them.
Hm one idea that just crossed my mind: Could we have a flag in fb_info for
fw drivers, and check this in framebuffer_register? Then at least all the
logic would be in the fbdev core.
I can't answer right away since I've since forgotten this part of the code
and will require to do a detailed read to refresh my memory.
I'll answer later but preferred to mention the other question ASAP.
quoted
Ok coffee just kicked in, how exactly does your scenario work?
This code I'm reverting here is in the platform_dev->probe function.
Thomas' patch removes the platform_dev. How exactly can you still probe
against a platform dev if that platform dev is gone?
Because the platform was not even registered by the time the DRM driver
probed and all the devices for the conflicting drivers were unregistered.
quoted
Iow, now that I reponder your case after a few weeks I'm no longer sure
things work like you claim.
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
-Daniel
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert Uytterhoeven wrote:
Hi Daniel,
On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter [off-list ref] wrote:
quoted
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.
I agree, that sounds odd.
The device should always stick around (as the bus creates it), it's up
to the driver to bind to the device as needed.
quoted
sense, and feels like the most proper linux device model solution
instead of hacks on top - if the firmware fb is unuseable because a
native driver has taken over, we should nuke that. And also the
firmware fb driver would then just bind to that platform_dev if it
exists, and only if it exists. Also I think it should be the
responsibility of whichever piece of code that registers these
platform devices to ensure that platform_dev actually still exists.
That's why I think pushing all that code into sysfb.c is probably the
cleanest solution.
Can't you unbind the generic driver first, and bind the specific driver
afterwards? Alike writing to sysfs unbind/driver_override/bind,
but from code?
That too feels odd, what is so special about the fbdev code that the
normal driver functions do not work for them? It shouldn't matter if
multiple subsystems register video devices, why can't we handle more
than one fb device?
thanks,
greg k-h
On Tue, Apr 05, 2022 at 06:12:59PM +0200, Daniel Vetter wrote:
On Tue, Apr 05, 2022 at 03:33:17PM +0200, Greg KH wrote:
quoted
On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert Uytterhoeven wrote:
quoted
Hi Daniel,
On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter [off-list ref] wrote:
quoted
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.
I agree, that sounds odd.
The device should always stick around (as the bus creates it), it's up
to the driver to bind to the device as needed.
The device actually disappears when the real driver takes over.
The firmware fb is a special thing which only really exists as long as the
firmware is in charge of the display hardware. As soon as a real driver
takes over, it stops being a thing.
And since a driver without a device is a bit a funny thing, we have been
pushing towards a model where the firmware code sets up a platform_device
for this fw interface, and the fw driver (efifb, simplefb and others like
that) bind against it. And then we started to throw out that
platform_device (which unbinds the fw driver and prevents it from ever
rebinding), except in the wrong layer so there's a few races.
Should we throw out all that code and replace it with something else? What
would that be like?
Ah, no, sorry, I didn't know that at all.
That sounds semi-sane, just fix the races by moving the layer elsewhere?
From: Daniel Vetter <hidden> Date: 2022-04-05 21:18:36
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
[snip]
quoted
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
sense, and feels like the most proper linux device model solution
instead of hacks on top - if the firmware fb is unuseable because a
native driver has taken over, we should nuke that. And also the
firmware fb driver would then just bind to that platform_dev if it
exists, and only if it exists. Also I think it should be the
responsibility of whichever piece of code that registers these
platform devices to ensure that platform_dev actually still exists.
That's why I think pushing all that code into sysfb.c is probably the
cleanest solution.
fbdev predates all that stuff by a lot, hence the hand-rolling.
But maybe Greg has some more thoughts here too?
-Daniel
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Daniel Vetter <hidden> Date: 2022-04-05 23:41:51
On Tue, Apr 05, 2022 at 03:33:17PM +0200, Greg KH wrote:
On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert Uytterhoeven wrote:
quoted
Hi Daniel,
On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter [off-list ref] wrote:
quoted
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.
I agree, that sounds odd.
The device should always stick around (as the bus creates it), it's up
to the driver to bind to the device as needed.
The device actually disappears when the real driver takes over.
The firmware fb is a special thing which only really exists as long as the
firmware is in charge of the display hardware. As soon as a real driver
takes over, it stops being a thing.
And since a driver without a device is a bit a funny thing, we have been
pushing towards a model where the firmware code sets up a platform_device
for this fw interface, and the fw driver (efifb, simplefb and others like
that) bind against it. And then we started to throw out that
platform_device (which unbinds the fw driver and prevents it from ever
rebinding), except in the wrong layer so there's a few races.
Should we throw out all that code and replace it with something else? What
would that be like?
Note that the fw side generally has not much clue which real device on
some bus it corresponds to, that part is done through a bunch of magic
tricks. Some of them are simply "I'm taking over a display, pls through
out all fw drivers just to be sure".
quoted
quoted
sense, and feels like the most proper linux device model solution
instead of hacks on top - if the firmware fb is unuseable because a
native driver has taken over, we should nuke that. And also the
firmware fb driver would then just bind to that platform_dev if it
exists, and only if it exists. Also I think it should be the
responsibility of whichever piece of code that registers these
platform devices to ensure that platform_dev actually still exists.
That's why I think pushing all that code into sysfb.c is probably the
cleanest solution.
Can't you unbind the generic driver first, and bind the specific driver
afterwards? Alike writing to sysfs unbind/driver_override/bind,
but from code?
That too feels odd, what is so special about the fbdev code that the
normal driver functions do not work for them? It shouldn't matter if
multiple subsystems register video devices, why can't we handle more
than one fb device?
The specific driver binds to a completely different device (this one is
more real), and sometimes has not much clue about what exactly the
fw/legacy driver is doing.
The special thing is that in fbdev we have "drivers" which are extremely
thin shims around the fw driver, which has done all the real display setup
for us. I don't think any other subsystem bothers with this, e.g. input
just tells the fw to get lost and never tries to use the fw input support
(stuff like the old horrors of emulating usb kbd as a ps/2 device and
things like that which fw tended to do). Only with display drivers do we
have this world where fairly often a fw driver is loaded first, and then
quite a bit later in the boot process, the real driver loads. It's a bit
like early serial console perhaps, to reduce the gap between when the
kernel loads and when the real display driver is ready.
Cheers, Daniel
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-04-06 00:17:43
On 4/5/22 11:24, Daniel Vetter wrote:
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
[snip]
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Let me know if you think that makes sense and I can attempt to write a fix.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hi Daniel,
On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter [off-list ref] wrote:
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.
sense, and feels like the most proper linux device model solution
instead of hacks on top - if the firmware fb is unuseable because a
native driver has taken over, we should nuke that. And also the
firmware fb driver would then just bind to that platform_dev if it
exists, and only if it exists. Also I think it should be the
responsibility of whichever piece of code that registers these
platform devices to ensure that platform_dev actually still exists.
That's why I think pushing all that code into sysfb.c is probably the
cleanest solution.
Can't you unbind the generic driver first, and bind the specific driver
afterwards? Alike writing to sysfs unbind/driver_override/bind,
but from code?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
From: Daniel Vetter <hidden> Date: 2022-04-06 00:35:15
On Tue, 5 Apr 2022 at 18:45, Greg KH [off-list ref] wrote:
On Tue, Apr 05, 2022 at 06:12:59PM +0200, Daniel Vetter wrote:
quoted
On Tue, Apr 05, 2022 at 03:33:17PM +0200, Greg KH wrote:
quoted
On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert Uytterhoeven wrote:
quoted
Hi Daniel,
On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter [off-list ref] wrote:
quoted
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.
I agree, that sounds odd.
The device should always stick around (as the bus creates it), it's up
to the driver to bind to the device as needed.
The device actually disappears when the real driver takes over.
The firmware fb is a special thing which only really exists as long as the
firmware is in charge of the display hardware. As soon as a real driver
takes over, it stops being a thing.
And since a driver without a device is a bit a funny thing, we have been
pushing towards a model where the firmware code sets up a platform_device
for this fw interface, and the fw driver (efifb, simplefb and others like
that) bind against it. And then we started to throw out that
platform_device (which unbinds the fw driver and prevents it from ever
rebinding), except in the wrong layer so there's a few races.
Should we throw out all that code and replace it with something else? What
would that be like?
Ah, no, sorry, I didn't know that at all.
That sounds semi-sane, just fix the races by moving the layer elsewhere?
Yeah essentially move it all into drivers/firmware/sysfb.c, for all
drivers, both the registering and the nuking, and warp that into a
local mutex. Currently parts is in there, parts is in fbmem.c, parts
in some of the drivers like vga16fb, and some drivers (iirc only offb)
still don't even have any platform_dev underneath their driver. So
ideally the drivers would all just have their platform_driver probe
functions, and that's it. It does mean though that some of that stuff
needs to be moved to sysfb.c or into the relevant fw code that sets
stuff up.
It'll take some, so really just a direction check before we move
further. You should get cc'ed on the patches (like with the sysfb
stuff) anyway. Sounds roughly right?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
From: Javier Martinez Canillas <javierm@redhat.com> Date: 2022-04-06 00:40:15
On 4/5/22 12:34, Daniel Vetter wrote:
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
[snip]
quoted
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
Yeah, you are correct.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
I think this is the cleaner option. And makes sense to consolidate all
the firmware drivers platform device registration to sysfb.c.
Already does for VIDEO_TYPE_EFI ("efi-framebuffer") and VIDEO_TYPE_VLFB
("vesa-framebuffer"), so need to also make it cope with VIDEO_TYPE_EGAC
and VIDEO_TYPE_VGAC ("vga16fb").
For offb is less clear since currently the offb driver does not really
use the Linux device model, that is the driver does not match a device
that's registered, there's no device which is the bug that was reported
to Thomas in the other thread.
It's unclear how to properly fix that since we will need to convert the
offb driver to register a platform driver and match against a device that
is registered by some platform code that parses the OF...
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
Yup, that would get messy indeed so not a good option.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
sense, and feels like the most proper linux device model solution
instead of hacks on top - if the firmware fb is unuseable because a
native driver has taken over, we should nuke that. And also the
firmware fb driver would then just bind to that platform_dev if it
exists, and only if it exists. Also I think it should be the
responsibility of whichever piece of code that registers these
platform devices to ensure that platform_dev actually still exists.
That's why I think pushing all that code into sysfb.c is probably the
cleanest solution.
Agreed. Not registering the platform devices if there is already a DRM
driver for the same device is what makes the most sense. What I don't
understand is how sysfb would know that if run after a DRM registration.
The only way that could know is if sysfb would keep a list of apertures
for all the DRM drivers registered or if the DRM core somewhat notifies
to sysfb that a native driver was already registered.
Another option and probably the cleanest although the harder solution is
to finally bite the bullet and make all the DRM drivers to request their
memory region.
Or as you mentioned in the past, to move that logic into the device model
and then not allow to register devices that require an overlapping region.
And there could be a request_mem_region_remove_conflicting() or something
that real DRM drivers could use to force a memory region request and make
the device model to unregister any device that may already have that mem.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
From: Daniel Vetter <hidden> Date: 2022-04-06 02:32:42
On Thu, Feb 10, 2022 at 08:43:36PM +0900, Tetsuo Handa wrote:
On 2022/02/09 6:08, Daniel Vetter wrote:
quoted
@@ -714,6 +700,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info, ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL); if (!ops) err = -ENOMEM;++ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor); } if (!err) {
Memory allocation fault injection will hit NULL pointer dereference.
The error handling here is convoluted and I got this wrong, but a later
patch to extract an fbcon_open() helper fixes it. I'll fix this small
bisect issue for v3 anyway, thanks for taking a look at the patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 05, 2022 at 07:29:22PM +0200, Daniel Vetter wrote:
On Tue, 5 Apr 2022 at 18:45, Greg KH [off-list ref] wrote:
quoted
On Tue, Apr 05, 2022 at 06:12:59PM +0200, Daniel Vetter wrote:
quoted
On Tue, Apr 05, 2022 at 03:33:17PM +0200, Greg KH wrote:
quoted
On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert Uytterhoeven wrote:
quoted
Hi Daniel,
On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter [off-list ref] wrote:
quoted
On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
[off-list ref] wrote:
quoted
On 4/5/22 11:24, Daniel Vetter wrote:
quoted
On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
quoted
This is how I think that work, please let me know if you see something
wrong in my logic:
1) A PCI device of OF device is registered for the GPU, this attempt to
match a registered driver but no driver was registered that match yet.
2) The efifb driver is built-in, will be initialized according to the link
order of the objects under drivers/video and the fbdev driver is registered.
There is no platform device or PCI/OF device registered that matches.
3) The DRM driver is built-in, will be initialized according to the link
order of the objects under drivers/gpu and the DRM driver is registered.
This matches the device registered in (1) and the DRM driver probes.
4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
before registering the DRM device.
There are no conflicting drivers or platform device at this point.
5) Latter at some point the drivers/firmware/sysfb.c init function is
executed, and this registers a platform device for the generic fb.
This device matches the efifb driver registered in (2) and the fbdev
driver probes.
Since that happens *after* the DRM driver already matched, probed
and registered the DRM device, that is a bug and what the reverted
patch worked around.
So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.
That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
I can attempt to write a patch for that.
Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.
For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.
I tried to minimize the issue for that particular driver with commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.
Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.
I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.
Hm that still feels like reinventing a driver model, badly.
I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.
quoted
Let me know if you think that makes sense and I can attempt to write a fix.
I still think unregistering the platform_dev properly makes the most
That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.
I agree, that sounds odd.
The device should always stick around (as the bus creates it), it's up
to the driver to bind to the device as needed.
The device actually disappears when the real driver takes over.
The firmware fb is a special thing which only really exists as long as the
firmware is in charge of the display hardware. As soon as a real driver
takes over, it stops being a thing.
And since a driver without a device is a bit a funny thing, we have been
pushing towards a model where the firmware code sets up a platform_device
for this fw interface, and the fw driver (efifb, simplefb and others like
that) bind against it. And then we started to throw out that
platform_device (which unbinds the fw driver and prevents it from ever
rebinding), except in the wrong layer so there's a few races.
Should we throw out all that code and replace it with something else? What
would that be like?
Ah, no, sorry, I didn't know that at all.
That sounds semi-sane, just fix the races by moving the layer elsewhere?
Yeah essentially move it all into drivers/firmware/sysfb.c, for all
drivers, both the registering and the nuking, and warp that into a
local mutex. Currently parts is in there, parts is in fbmem.c, parts
in some of the drivers like vga16fb, and some drivers (iirc only offb)
still don't even have any platform_dev underneath their driver. So
ideally the drivers would all just have their platform_driver probe
functions, and that's it. It does mean though that some of that stuff
needs to be moved to sysfb.c or into the relevant fw code that sets
stuff up.
It'll take some, so really just a direction check before we move
further. You should get cc'ed on the patches (like with the sysfb
stuff) anyway. Sounds roughly right?