Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44 |
|
#
66d658b9 |
| 03-Aug-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/efifb: Use fbdev I/O helpers
Set struct fb_ops and with FB_DEFAULT_IOMEM_OPS, fbdev's initializer for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions. Select the correct module
fbdev/efifb: Use fbdev I/O helpers
Set struct fb_ops and with FB_DEFAULT_IOMEM_OPS, fbdev's initializer for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions. Select the correct modules with Kconfig's FB_IOMEM_HELPERS token.
The macro and token set the currently selected values, so there is no functional change.
v3: * use _IOMEM_ in commit message v2: * updated to use _IOMEM_ tokens
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Helge Deller <deller@gmx.de> Cc: Peter Jones <pjones@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803184034.6456-10-tzimmermann@suse.de
show more ...
|
Revision tags: v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
8a4675eb |
| 15-Jul-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). S
fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed.
v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Jaya Kumar <jayalk@intworks.biz> Cc: Helge Deller <deller@gmx.de> Cc: Peter Jones <pjones@redhat.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Maik Broemme <mbroemme@libmpq.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com> Cc: Michal Januszewski <spock@gentoo.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-15-tzimmermann@suse.de
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
156ebfe4 |
| 18-Mar-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
fbdev: efifb: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error
fbdev: efifb: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Helge Deller <deller@gmx.de>
show more ...
|
Revision tags: v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15 |
|
#
7191ec80 |
| 19-Dec-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/efifb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO
fbdev/efifb: Do not use struct fb_info.apertures
Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
show more ...
|
#
82dcb90b |
| 19-Dec-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/efifb: Add struct efifb_par for driver data
The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range.
Signed-off-by: Thomas Zimmerma
fbdev/efifb: Add struct efifb_par for driver data
The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-11-tzimmermann@suse.de
show more ...
|
Revision tags: v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46 |
|
#
bdde97ac |
| 07-Jun-2022 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d Aut
Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d Author: Thomas Zimmermann <tzimmermann@suse.de> 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 <zackr@vmware.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Zack Rusin <zackr@vmware.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ilya Trukhanov <lahvuun@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220607182338.344270-5-javierm@redhat.com
show more ...
|
Revision tags: v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38 |
|
#
1b5853df |
| 06-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: efifb: Fix a use-after-free due early fb_info cleanup
Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove") attempted to fix a use-after-free error due driv
fbdev: efifb: Fix a use-after-free due early fb_info cleanup
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ä <ville.syrjala@linux.intel.com> Reported-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Thomas Zimmermann <tzimemrmann@suse.de> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220506132225.588379-1-javierm@redhat.com
show more ...
|
#
d258d00f |
| 05-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Si
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
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 <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220505220540.366218-1-javierm@redhat.com
show more ...
|
Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2 |
|
#
fb561bf9 |
| 11-Nov-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: Prevent probing generic drivers if a FB is already registered
The efifb and simplefb drivers just render to a pre-allocated frame buffer and rely on the display hardware being initialized bef
fbdev: Prevent probing generic drivers if a FB is already registered
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 <lahvuun@gmail.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Ilya Trukhanov <lahvuun@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211111115757.1351045-1-javierm@redhat.com
show more ...
|
Revision tags: v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
55285e21 |
| 09-Aug-2021 |
Imre Deak <imre.deak@intel.com> |
fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
Atm the EFI FB platform driver gets a runtime PM reference for the associated GFX PCI device during probing the EFI FB platform dev
fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
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 <kai.heng.feng@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210809133146.2478382-1-imre.deak@intel.com
show more ...
|
#
ef090cd4 |
| 06-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: efifb: Fix a use-after-free due early fb_info cleanup
[ Upstream commit 1b5853dfab7fdde450f00f145327342238135c8a ]
Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather t
fbdev: efifb: Fix a use-after-free due early fb_info cleanup
[ Upstream commit 1b5853dfab7fdde450f00f145327342238135c8a ]
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ä <ville.syrjala@linux.intel.com> Reported-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Thomas Zimmermann <tzimemrmann@suse.de> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220506132225.588379-1-javierm@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
cd3c8abb |
| 05-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
[ Upstream commit d258d00fb9c7c0cdf9d10c1ded84f10339d2d349 ]
The driver is calling framebuffer_release() in its .remove callback, bu
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
[ Upstream commit d258d00fb9c7c0cdf9d10c1ded84f10339d2d349 ]
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 <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220505220540.366218-1-javierm@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
90342e02 |
| 11-Nov-2021 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: Prevent probing generic drivers if a FB is already registered
commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee upstream.
The efifb and simplefb drivers just render to a pre-allocated frame bu
fbdev: Prevent probing generic drivers if a FB is already registered
commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee upstream.
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 <lahvuun@gmail.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Ilya Trukhanov <lahvuun@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211111115757.1351045-1-javierm@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e3b39825 |
| 09-Aug-2021 |
Imre Deak <imre.deak@intel.com> |
fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
[ Upstream commit 55285e21f04517939480966164a33898c34b2af2 ]
Atm the EFI FB platform driver gets a runtime PM reference for the as
fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
[ Upstream commit 55285e21f04517939480966164a33898c34b2af2 ]
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 <kai.heng.feng@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210809133146.2478382-1-imre.deak@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
74deef03 |
| 13-Apr-2021 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
efifb: Check efifb_pci_dev before using it
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: a6c0fd
efifb: Check efifb_pci_dev before using it
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 <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413170508.968148-1-kai.heng.feng@canonical.com
show more ...
|
#
d510c88c |
| 13-Apr-2021 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
efifb: Check efifb_pci_dev before using it
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: a6c0fd
efifb: Check efifb_pci_dev before using it
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 <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210413170508.968148-1-kai.heng.feng@canonical.com
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
a6c0fd3d |
| 29-Jan-2021 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
efifb: Ensure graphics device for efifb stays at PCI D0
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
efifb: Ensure graphics device for efifb stays at PCI D0
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 <kai.heng.feng@canonical.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210129084327.986630-1-kai.heng.feng@canonical.com
show more ...
|
Revision tags: v5.10 |
|
#
86925b9f |
| 06-Dec-2020 |
Sam Ravnborg <sam@ravnborg.org> |
video: fbdev: efifb: Fix set but not used warning for screen_pitch
screen_pitch was asssigned a value which was never used. Drop it to fix the warning
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
video: fbdev: efifb: Fix set but not used warning for screen_pitch
screen_pitch was asssigned a value which was never used. Drop it to fix the warning
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Peter Jones <pjones@redhat.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20201206190247.1861316-12-sam@ravnborg.org
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9 |
|
#
6163a985 |
| 10-Jul-2020 |
Juergen Gross <jgross@suse.com> |
efi: avoid error message when booting under Xen
efifb_probe() will issue an error message in case the kernel is booted as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid that messa
efi: avoid error message when booting under Xen
efifb_probe() will issue an error message in case the kernel is booted as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set.
Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Juergen Gross <jgross@suse.com>
show more ...
|
Revision tags: v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2 |
|
#
8a48ac33 |
| 03-Dec-2019 |
Jani Nikula <jani.nikula@intel.com> |
video: constify fb ops across all drivers
Now that the fbops member of struct fb_info is const, we can start making the ops const as well.
This does not cover all drivers; some actually modify the
video: constify fb ops across all drivers
Now that the fbops member of struct fb_info is const, we can start making the ops const as well.
This does not cover all drivers; some actually modify the fbops struct, for example to adjust for different configurations, and others do more involved things that I'd rather not touch in practically obsolete drivers. Mostly this is the low hanging fruit where we can add "const" and be done with it.
v3: - un-constify atyfb, mb862xx, nvidia and uvesabf (0day)
v2: - fix typo (Christophe de Dinechin) - use "static const" instead of "const static" in mx3fb.c - also constify smscufx.c
Cc: linux-fbdev@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce67f14435f3af498f2e8bf35ce4be11f7504132.1575390740.git.jani.nikula@intel.com
show more ...
|
Revision tags: v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2 |
|
#
c9c13ba4 |
| 27-Sep-2019 |
Denis Efremov <efremov@linux.com> |
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RE
PCI: Add PCI_STD_NUM_BARS for the number of standard BARs
Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, that requires the unusual test "i <= PCI_STD_RESOURCE_END" rather than something the typical "i < PCI_STD_NUM_BARS".
Add a definition for PCI_STD_NUM_BARS and change loops to use the more idiomatic C style to help avoid fencepost errors.
Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.com Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.ibm.com> # arch/s390/ Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> # video/fbdev/ Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> # pci/controller/dwc/ Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> # scsi/pm8001/ Acked-by: Martin K. Petersen <martin.petersen@oracle.com> # scsi/pm8001/ Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # memstick/
show more ...
|
Revision tags: v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3 |
|
#
51677dfc |
| 21-Jul-2019 |
Hans de Goede <hdegoede@redhat.com> |
efifb: BGRT: Improve efifb_bgrt_sanity_check
For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable.
Extensive testing has shown that
efifb: BGRT: Improve efifb_bgrt_sanity_check
For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable.
Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable).
This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not.
This fixes the BGRT image sometimes being drawn in the wrong place.
Cc: stable@vger.kernel.org Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190721131918.10115-1-hdegoede@redhat.com
show more ...
|
Revision tags: v5.2.2, v5.2.1, v5.2, v5.1.16 |
|
#
0adcdbcb |
| 28-Jun-2019 |
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> |
video: fbdev: don't print error message on framebuffer_alloc() failure
framebuffer_alloc() can fail only on kzalloc() memory allocation failure and since kzalloc() will print error message in such c
video: fbdev: don't print error message on framebuffer_alloc() failure
framebuffer_alloc() can fail only on kzalloc() memory allocation failure and since kzalloc() will print error message in such case we can omit printing extra error message in drivers (which BTW is what the majority of framebuffer_alloc() users is doing already).
Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
show more ...
|
Revision tags: v5.1.15, v5.1.14, v5.1.13 |
|
#
b6b1d511 |
| 21-Jun-2019 |
Hans de Goede <hdegoede@redhat.com> |
efifb: BGRT: Add check for new BGRT status field rotation bits
Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image n
efifb: BGRT: Add check for new BGRT status field rotation bits
Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image needs to be rotated before being displayed.
The efifb code does not support rotating the image before copying it to the screen.
This commit adds a check for these new bits and if they are set leaves the fb contents as is instead of trying to use the un-rotated BGRT image.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
show more ...
|
Revision tags: v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
f8585539 |
| 16-May-2019 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types
The following commit:
38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
updated the EF
fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types
The following commit:
38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
updated the EFI framebuffer code to use memory mappings for the linear framebuffer that are permitted by the memory attributes described by the EFI memory map for the particular region, if the framebuffer happens to be covered by the EFI memory map (which is typically only the case for framebuffers in shared memory). This is required since non-x86 systems may require cacheable attributes for memory mappings that are shared with other masters (such as GPUs), and this information cannot be described by the Graphics Output Protocol (GOP) EFI protocol itself, and so we rely on the EFI memory map for this.
As reported by James, this breaks some x86 systems:
[ 1.173368] efifb: probing for efifb [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf800000 [ 1.173395] Trying to free nonexistent resource <00000000cf800000-00000000cf9d4bff> [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5
The problem turns out to be that the memory map entry that describes the framebuffer has no memory attributes listed at all, and so we end up with a mem_flags value of 0x0.
So work around this by ensuring that the memory map entry's attribute field has a sane value before using it to mask the set of usable attributes.
Reported-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # v4.19+ Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...") Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|