kernel/linux.git/drivers/video/fbdev/efifb.c, branch v6.1.168

fbdev: efifb: Register sysfs groups through driver core

2024-12-14T18:53:13+00:00

[ Upstream commit 95cdd538e0e5677efbdf8aade04ec098ab98f457 ] The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. Signed-off-by: Thomas Weißschuh Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Signed-off-by: Xiangyu Chen Signed-off-by: Sasha Levin

Merge tag 'drm-misc-next-2022-06-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2022-06-22T00:33:09+00:00

drm-misc-next for v5.20: UAPI Changes: Cross-subsystem Changes: * dma-buf: Add sync-file API; Set DMA mask for udmabuf devices * fbcon: Cleanups * fbdev: Disable firmware-device registration when first native driver loads * iosys-map: Documentation fixes Core Changes: * edid: Use struct drm_edid in more places * gem-cma-helper: Improve documentation * of: Add data-lane helpers and convert drivers * syncobj: Fixes Driver Changes: * amdgpu: Build fixes * ast: Support multiple outputs * bochs: Include * bridge: adv7511: I2C fixes; anx7625: Fix error handling; lt6505: Kconfig fixes * display/dp: Documentation fixes * display/dp-mst: Read extended DPCD capabilities during system resume * logicvc: Add new driver * magag200: Build fixes * nouveau: Cleanups * panel: Add backlight support; nt36672a: DT backlight support * qxl: Cleanups * sun4i: HDMI PHY cleanups * vc4: Add support for BCM2711 * virt-gpu: Avoid NULL dereference; Fix error checks; Cleanups * vkms: Allocate output buffer with vmalloc(); Fixes Signed-off-by: Dave Airlie From: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/YqwriEhn0l4uO+Gn@linux-uq9g

Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

2022-06-09T14:22:03+00:00

This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee. With commit 27599aacbaefcbf2af7b06b0029459bbf682000d Author: Thomas Zimmermann 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 Cc: Zack Rusin Cc: Javier Martinez Canillas Cc: Zack Rusin Cc: Hans de Goede Cc: Ilya Trukhanov Signed-off-by: Daniel Vetter Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Cc: Peter Jones Cc: linux-fbdev@vger.kernel.org Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-5-javierm@redhat.com

fbdev: efifb: Fix a use-after-free due early fb_info cleanup

2022-05-07T16:05:48+00:00

Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove") attempted to fix a use-after-free error due driver freeing the fb_info in the .remove handler instead of doing it in .fb_destroy. But ironically that change introduced yet another use-after-free since the fb_info was still used after the free. This should fix for good by freeing the fb_info at the end of the handler. Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove") Reported-by: Ville Syrjälä Reported-by: Andrzej Hajda Signed-off-by: Javier Martinez Canillas Reviewed-by: Andi Shyti Reviewed-by: Andrzej Hajda Reviewed-by: Thomas Zimmermann Signed-off-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20220506132225.588379-1-javierm@redhat.com

fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove

2022-05-06T07:21:22+00:00

The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Since it could be that a reference is still hold to it if user-space opened the fbdev. This would lead to a use-after-free error if the framebuffer device was unregistered but later a user-space process tries to close the fbdev fd. To prevent this, move the framebuffer_release() call to fb_ops.fb_destroy instead of doing it in the driver's .remove callback. Strictly speaking, the code flow in the driver is still wrong because all the hardware cleanupd (i.e: iounmap) should be done in .remove while the software cleanup (i.e: releasing the framebuffer) should be done in the .fb_destroy handler. But this at least makes to match the behavior before commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"). Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") Suggested-by: Daniel Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220505220540.366218-1-javierm@redhat.com

fbdev: Prevent probing generic drivers if a FB is already registered

2021-11-17T09:15:05+00:00

The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized before the kernel boots. But if another driver already probed correctly and registered a fbdev, the generic drivers shouldn't be probed since an actual driver for the display hardware is already present. This is more likely to occur after commit d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") since the "efi-framebuffer" and "simple-framebuffer" platform devices are registered at a later time. Link: https://lore.kernel.org/r/20211110200253.rfudkt3edbd3nsyj@lahvuun/ Fixes: d391c5827107 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by: Ilya Trukhanov Cc: # 5.15.x Signed-off-by: Javier Martinez Canillas Reviewed-by: Daniel Vetter Tested-by: Ilya Trukhanov Link: https://patchwork.freedesktop.org/patch/msgid/20211111115757.1351045-1-javierm@redhat.com

fbdev/efifb: Release PCI device's runtime PM ref during FB destroy

2021-08-13T13:38:04+00:00

Atm the EFI FB platform driver gets a runtime PM reference for the associated GFX PCI device during probing the EFI FB platform device and releases it only when the platform device gets unbound. When fbcon switches to the FB provided by the PCI device's driver (for instance i915/drmfb), the EFI FB will get only unregistered without the EFI FB platform device getting unbound, keeping the runtime PM reference acquired during the platform device probing. This reference will prevent the PCI driver from runtime suspending the device. Fix this by releasing the RPM reference from the EFI FB's destroy hook, called when the FB gets unregistered. While at it assert that pm_runtime_get_sync() didn't fail. v2: - Move pm_runtime_get_sync() before register_framebuffer() to avoid its race wrt. efifb_destroy()->pm_runtime_put(). (Daniel) - Assert that pm_runtime_get_sync() didn't fail. - Clarify commit message wrt. platform/PCI device/driver and driver removal vs. device unbinding. Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") Cc: Kai-Heng Feng Cc: Daniel Vetter Reviewed-by: Daniel Vetter (v1) Acked-by: Alex Deucher Acked-by: Kai-Heng Feng Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20210809133146.2478382-1-imre.deak@intel.com

efifb: Check efifb_pci_dev before using it

2021-04-26T21:33:03+00:00

On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not a PCI device. So make sure efifb_pci_dev is found before using it. Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") BugLink: https://bugs.launchpad.net/bugs/1922403 Signed-off-by: Kai-Heng Feng Signed-off-by: Alex Deucher Reviewed-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20210413170508.968148-1-kai.heng.feng@canonical.com

efifb: Ensure graphics device for efifb stays at PCI D0

2021-02-22T07:55:50+00:00

We are seeing root ports on some desktop boards support D3cold for discrete graphics card. So when efifb is in use while graphics device isn't bound to a driver, PCI and ACPI will put the graphics to D3cold when runtime suspend kicks in, makes efifb stop working. So ensure the graphics device won't be runtime suspended, to keep efifb work all the time. Signed-off-by: Kai-Heng Feng Reviewed-by: Alex Deucher Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210129084327.986630-1-kai.heng.feng@canonical.com

video: fbdev: efifb: Fix set but not used warning for screen_pitch

2020-12-08T17:36:03+00:00

screen_pitch was asssigned a value which was never used. Drop it to fix the warning Signed-off-by: Sam Ravnborg Acked-by: Thomas Zimmermann Cc: Peter Jones Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20201206190247.1861316-12-sam@ravnborg.org