linux-stable.git/drivers/firmware/sysfb.c, branch v6.10 Linux kernel stable tree firmware: sysfb: Fix reference count of sysfb parent device 2024-06-28T06:50:33+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-06-25T08:17:43+00:00 3285d8f0a2ede604c368155c9c0921e16d41f70a Retrieving the system framebuffer's parent device in sysfb_init() increments the parent device's reference count. Hence release the reference before leaving the init function. Adding the sysfb platform device acquires and additional reference for the parent. This keeps the parent device around while the system framebuffer is in use. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Helge Deller <deller@gmx.de> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: <stable@vger.kernel.org> # v6.9+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240625081818.15696-1-tzimmermann@suse.de 
Retrieving the system framebuffer's parent device in sysfb_init()
increments the parent device's reference count. Hence release the
reference before leaving the init function.

Adding the sysfb platform device acquires and additional reference
for the parent. This keeps the parent device around while the system
framebuffer is in use.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Sui Jingfeng <suijingfeng@loongson.cn>
Cc: <stable@vger.kernel.org> # v6.9+
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240625081818.15696-1-tzimmermann@suse.de
firmware/sysfb: fix an error code in sysfb_init() 2024-02-27T08:21:06+00:00 Dan Carpenter dan.carpenter@linaro.org 2024-02-22T06:13:21+00:00 9fa2679b7fe1bf4e6010051767d3c163b3aee68b This error path accidentally returns success when it should preserve the error code from sysfb_parent_dev(). Fixes: 4e754597d603 ("firmware/sysfb: Create firmware device only for enabled PCI devices") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/aaaa2e13-849b-41a0-8186-25f3d2a16f86@moroto.mountain 
This error path accidentally returns success when it should preserve the
error code from sysfb_parent_dev().

Fixes: 4e754597d603 ("firmware/sysfb: Create firmware device only for enabled PCI devices")
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/aaaa2e13-849b-41a0-8186-25f3d2a16f86@moroto.mountain
firmware/sysfb: Update screen_info for relocated EFI framebuffers 2024-02-14T09:09:21+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-02-12T09:06:15+00:00 78aa89d1dfba1e3cf4a2e053afa3b4c4ec622371 On ARM PCI systems, the PCI hierarchy might be reconfigured during boot and the firmware framebuffer might move as a result of that. The values in screen_info will then be invalid. Work around this problem by tracking the framebuffer's initial location before it get relocated; then fix the screen_info state between reloaction and creating the firmware framebuffer's device. This functionality has been lifted from efifb. See the commit message of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer") for more information. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-8-tzimmermann@suse.de 
On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.

Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_info state
between reloaction and creating the firmware framebuffer's device.

This functionality has been lifted from efifb. See the commit message
of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that
covers the framebuffer") for more information.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-8-tzimmermann@suse.de
firmware/sysfb: Create firmware device only for enabled PCI devices 2024-02-14T09:09:18+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-02-12T09:06:13+00:00 4e754597d603c642869be9bffbb0ef49bf5f7bb8 Test if the firmware framebuffer's parent PCI device, if any, has been enabled. If not, the firmware framebuffer is most likely not working. Hence, do not create a device for the firmware framebuffer on disabled PCI devices. So far, efifb tracked the status of the PCI parent device internally and did not bind if it was disabled. This patch implements the functionality for all PCI-based firmware framebuffers. v3: * make commit message more precise (Sui) v2: * rework sysfb_pci_dev_is_enabled() (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-6-tzimmermann@suse.de 
Test if the firmware framebuffer's parent PCI device, if any, has
been enabled. If not, the firmware framebuffer is most likely not
working. Hence, do not create a device for the firmware framebuffer
on disabled PCI devices.

So far, efifb tracked the status of the PCI parent device internally
and did not bind if it was disabled. This patch implements the
functionality for all PCI-based firmware framebuffers.

v3:
	* make commit message more precise (Sui)
v2:
	* rework sysfb_pci_dev_is_enabled() (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-6-tzimmermann@suse.de
firmware/sysfb: Set firmware-framebuffer parent device 2024-02-14T09:09:17+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-02-12T09:06:11+00:00 9eac534db0013aff9b9124985dab114600df9081 Set the firmware framebuffer's parent device, which usually is the graphics hardware's physical device. Integrates the framebuffer in the Linux device hierarchy and lets Linux handle dependencies among devices. For example, the graphics hardware won't be suspended while the firmware device is still active. v4: * fix build for CONFIG_SYSFB_SIMPLEFB=n, again v3: * fix build for CONFIG_SYSFB_SIMPLEFB=n (Sui) * test result of screen_info_pci_dev() for errors (Sui) v2: * detect parent device in sysfb_parent_dev() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-4-tzimmermann@suse.de 
Set the firmware framebuffer's parent device, which usually is the
graphics hardware's physical device. Integrates the framebuffer in
the Linux device hierarchy and lets Linux handle dependencies among
devices. For example, the graphics hardware won't be suspended while
the firmware device is still active.

v4:
	* fix build for CONFIG_SYSFB_SIMPLEFB=n, again
v3:
	* fix build for CONFIG_SYSFB_SIMPLEFB=n (Sui)
	* test result of screen_info_pci_dev() for errors (Sui)
v2:
	* detect parent device in sysfb_parent_dev()

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-4-tzimmermann@suse.de
Revert "drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync" 2024-01-24T16:03:44+00:00 Thomas Zimmermann tzimmermann@suse.de 2024-01-23T12:09:26+00:00 d1b163aa0749706379055e40a52cf7a851abf9dc This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4. Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync") messes up initialization order of the graphics drivers and leads to blank displays on some systems. So revert the commit. To make the display drivers fully independent from initialization order requires to track framebuffer memory by device and independently from the loaded drivers. The kernel currently lacks the infrastructure to do so. Reported-by: Jaak Ristioja <jaak@ristioja.ee> Closes: https://lore.kernel.org/dri-devel/ZUnNi3q3yB3zZfTl@P70.localdomain/T/#t Reported-by: Huacai Chen <chenhuacai@loongson.cn> Closes: https://lore.kernel.org/dri-devel/20231108024613.2898921-1-chenhuacai@loongson.cn/ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10133 Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: stable@vger.kernel.org # v6.5+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240123120937.27736-1-tzimmermann@suse.de 
This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4.

Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
device_initcall to subsys_initcall_sync") messes up initialization order
of the graphics drivers and leads to blank displays on some systems. So
revert the commit.

To make the display drivers fully independent from initialization
order requires to track framebuffer memory by device and independently
from the loaded drivers. The kernel currently lacks the infrastructure
to do so.

Reported-by: Jaak Ristioja <jaak@ristioja.ee>
Closes: https://lore.kernel.org/dri-devel/ZUnNi3q3yB3zZfTl@P70.localdomain/T/#t
Reported-by: Huacai Chen <chenhuacai@loongson.cn>
Closes: https://lore.kernel.org/dri-devel/20231108024613.2898921-1-chenhuacai@loongson.cn/
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10133
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: stable@vger.kernel.org # v6.5+
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240123120937.27736-1-tzimmermann@suse.de
drivers/firmware: Move sysfb_init() from device_initcall to subsys_initcall_sync 2023-05-15T11:36:30+00:00 Huacai Chen chenhuacai@loongson.cn 2022-07-04T01:17:04+00:00 60aebc9559492cea6a9625f514a8041717e3a2e4 Consider a configuration like this: 1, efifb (or simpledrm) is built-in; 2, a native display driver (such as radeon) is also built-in. As Javier said, this is not a common configuration (the native display driver is usually built as a module), but it can happen and cause some trouble. In this case, since efifb, radeon and sysfb are all in device_initcall() level, the order in practise is like this: efifb registered at first, but no "efi-framebuffer" device yet. radeon registered later, and /dev/fb0 created. sysfb_init() comes at last, it registers "efi-framebuffer" and then causes an error message "efifb: a framebuffer is already registered". Make sysfb_init() to be subsys_ initcall_sync() can avoid this. And Javier Martinez Canillas is trying to make a more general solution in commit 873eb3b11860 ("fbdev: Disable sysfb device registration when removing conflicting FBs"). However, this patch still makes sense because it can make the screen display as early as possible (We cannot move to subsys_initcall, since sysfb_init() should be executed after PCI enumeration). Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220704011704.1418055-1-chenhuacai@loongson.cn 
Consider a configuration like this:
1, efifb (or simpledrm) is built-in;
2, a native display driver (such as radeon) is also built-in.

As Javier said, this is not a common configuration (the native display
driver is usually built as a module), but it can happen and cause some
trouble.

In this case, since efifb, radeon and sysfb are all in device_initcall()
level, the order in practise is like this:

efifb registered at first, but no "efi-framebuffer" device yet. radeon
registered later, and /dev/fb0 created. sysfb_init() comes at last, it
registers "efi-framebuffer" and then causes an error message "efifb: a
framebuffer is already registered". Make sysfb_init() to be subsys_
initcall_sync() can avoid this. And Javier Martinez Canillas is trying
to make a more general solution in commit 873eb3b11860 ("fbdev: Disable
sysfb device registration when removing conflicting FBs").

However, this patch still makes sense because it can make the screen
display as early as possible (We cannot move to subsys_initcall, since
sysfb_init() should be executed after PCI enumeration).

Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220704011704.1418055-1-chenhuacai@loongson.cn
efi: sysfb_efi: Fix DMI quirks not working for simpledrm 2023-03-18T10:44:57+00:00 Hans de Goede hdegoede@redhat.com 2023-03-14T12:31:02+00:00 3615c78673c332b69aaacefbcde5937c5c706686 Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") moved the sysfb_apply_efi_quirks() call in sysfb_init() from before the [sysfb_]parse_mode() call to after it. But sysfb_apply_efi_quirks() modifies the global screen_info struct which [sysfb_]parse_mode() parses, so doing it later is too late. This has broken all DMI based quirks for correcting wrong firmware efifb settings when simpledrm is used. To fix this move the sysfb_apply_efi_quirks() call back to its old place and split the new setup of the efifb_fwnode (which requires the platform_device) into its own function and call that at the place of the moved sysfb_apply_efi_quirks(pd) calls. Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Cc: stable@vger.kernel.org Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> 
Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup
for all arches") moved the sysfb_apply_efi_quirks() call in sysfb_init()
from before the [sysfb_]parse_mode() call to after it.
But sysfb_apply_efi_quirks() modifies the global screen_info struct which
[sysfb_]parse_mode() parses, so doing it later is too late.

This has broken all DMI based quirks for correcting wrong firmware efifb
settings when simpledrm is used.

To fix this move the sysfb_apply_efi_quirks() call back to its old place
and split the new setup of the efifb_fwnode (which requires
the platform_device) into its own function and call that at
the place of the moved sysfb_apply_efi_quirks(pd) calls.

Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches")
Cc: stable@vger.kernel.org
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
fbdev/vga16fb: Create EGA/VGA devices in sysfb code 2022-07-19T11:19:11+00:00 Thomas Zimmermann tzimmermann@suse.de 2022-07-18T07:23:13+00:00 0db5b61e0dc07cee121e5a04932ca7f5d0b62f6a Move the device-creation from vga16fb to sysfb code. The driver's videomode checks are independent from device creation, so move them into vga16fb's probe function. This will allow to create the module init/exit code automatically. The vga16fb driver requires a screen_info for type VIDEO_TYPE_VGAC or VIDEO_TYPE_EGAC. Such code is nowhere present in the kernel, except for some MIPS systems. It's not clear if the vga16fb driver actually works in practice. v2: * keep driver name to "vga16fb" (Javier) * give rational for moving mode checks (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-3-tzimmermann@suse.de 
Move the device-creation from vga16fb to sysfb code. The driver's
videomode checks are independent from device creation, so move them
into vga16fb's probe function. This will allow to create the module
init/exit code automatically.

The vga16fb driver requires a screen_info for type VIDEO_TYPE_VGAC
or VIDEO_TYPE_EGAC. Such code is nowhere present in the kernel, except
for some MIPS systems. It's not clear if the vga16fb driver actually
works in practice.

v2:
	* keep driver name to "vga16fb" (Javier)
	* give rational for moving mode checks (Javier)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-3-tzimmermann@suse.de
firmware: sysfb: Add sysfb_disable() helper function 2022-06-09T14:15:36+00:00 Javier Martinez Canillas javierm@redhat.com 2022-06-07T18:23:35+00:00 bc824922b264aff40eba8c160972ee07a95e7dd4 This can be used by subsystems to unregister a platform device registered by sysfb and also to disable future platform device registration in sysfb. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-3-javierm@redhat.com 
This can be used by subsystems to unregister a platform device registered
by sysfb and also to disable future platform device registration in sysfb.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-3-javierm@redhat.com