kernel/linux.git/drivers/video/fbdev/vesafb.c, branch v6.6.132

fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes

2024-08-11T10:47:16+00:00

[ Upstream commit c2bc958b2b03e361f14df99983bc64a39a7323a3 ] Test the vesa_attributes field in struct screen_info for compatibility with VGA hardware. Vesafb currently tests bit 1 in screen_info's capabilities field which indicates a 64-bit lfb address and is unrelated to VGA compatibility. Section 4.4 of the Vesa VBE 2.0 specifications defines that bit 5 in the mode's attributes field signals VGA compatibility. The mode is compatible with VGA hardware if the bit is clear. In that case, the driver can access VGA state of the VBE's underlying hardware. The vesafb driver uses this feature to program the color LUT in palette modes. Without, colors might be incorrect. The problem got introduced in commit 89ec4c238e7a ("[PATCH] vesafb: Fix incorrect logo colors in x86_64"). It incorrectly stores the mode attributes in the screen_info's capabilities field and updates vesafb accordingly. Later, commit 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code") fixed the screen_info, but did not update vesafb. Color output still tends to work, because bit 1 in capabilities is usually 0. Besides fixing the bug in vesafb, this commit introduces a helper that reads the correct bit from screen_info. Signed-off-by: Thomas Zimmermann Fixes: 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code") Reviewed-by: Javier Martinez Canillas Cc: # v2.6.23+ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev/vesafb: Replace references to global screen_info by local pointer

2024-08-11T10:47:15+00:00

[ Upstream commit 3218286bbb78cac3dde713514529e0480d678173 ] Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-4-tzimmermann@suse.de Stable-dep-of: c2bc958b2b03 ("fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes") Signed-off-by: Sasha Levin

fbdev/vesafb: Use fbdev I/O helpers

2023-08-04T13:54:38+00:00

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 Reviewed-by: Sam Ravnborg Acked-by: Helge Deller Link: https://patchwork.freedesktop.org/patch/msgid/20230803184034.6456-46-tzimmermann@suse.de

fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs

2023-07-24T14:50:39+00:00

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 Acked-by: Sam Ravnborg Cc: Jaya Kumar Cc: Helge Deller Cc: Peter Jones Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Shawn Guo Cc: Fabio Estevam Cc: NXP Linux Team Cc: Maik Broemme Cc: Jingoo Han Cc: Sudip Mukherjee Cc: Teddy Wang Cc: Michal Januszewski Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-15-tzimmermann@suse.de

fbdev: vesafb: Convert to platform remove callback returning void

2023-04-24T09:48:32+00:00

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 Signed-off-by: Helge Deller

fbdev/vesafb: Do not use struct fb_info.apertures

2023-01-13T11:54:33+00:00

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 Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-17-tzimmermann@suse.de

fbdev/vesafb: Remove trailing whitespaces

2023-01-13T11:54:32+00:00

Fix coding style. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-16-tzimmermann@suse.de

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

2022-05-28T17:26:56+00:00

Commit b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove") fixed a use-after-free error due the vesafb driver freeing the fb_info in the .remove handler instead of doing it in .fb_destroy. This can happen if the .fb_destroy callback is executed after the .remove callback, since the former tries to access a pointer freed by the latter. But that change didn't take into account that another possible scenario is that .fb_destroy is called before the .remove callback. For example, if no process has the fbdev chardev opened by the time the driver is removed. If that's the case, fb_info will be freed when unregister_framebuffer() is called, making the fb_info pointer accessed in vesafb_remove() after that to no longer be valid. To prevent that, move the expression containing the info->par to happen before the unregister_framebuffer() function call. Fixes: b3c9a924aab6 ("fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove") Reported-by: Pascal Ernster Signed-off-by: Javier Martinez Canillas Tested-by: Pascal Ernster Signed-off-by: Helge Deller

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

2022-05-06T07:25:49+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/20220505220631.366371-1-javierm@redhat.com

video: fbdev: vesafb: add missed release_region

2020-04-17T13:50:14+00:00

The driver forgets to free the I/O region in remove and probe failure. Add the missed calls to fix it. Since the success of request_region() is optional, add the "region" field in vesafb_par to represent whether request_region() succeeds. Then only call release_region() when "region" is not null. Signed-off-by: Chuhong Yuan Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200329145839.20076-1-hslester96@gmail.com