#
15260979 |
|
15-Mar-2024 |
Samuel Thibault <samuel.thibault@ens-lyon.org> |
fbcon: Increase maximum font width x height to 64 x 128 By using bitmaps we actually support whatever size we would want, but the console currently limits fonts to 64x128 (which gives 60x16 text on 4k screens), so we don't need more for now, and we can easily increase later. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Helge Deller <deller@gmx.de>
|
#
71fc3249 |
|
18-Jan-2024 |
Thomas Zimmermann <tzimmermann@suse.de> |
video/nomodeset: Select nomodeset= parameter with CONFIG_VIDEO Enable support for nomodeset= parameter via CONFIG_VIDEO. Both, DRM and fbdev, already select this option. Remove the existing option CONFIG_VIDEO_NOMODESET. Simplifies the Kconfig rules. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20240118090721.7995-4-tzimmermann@suse.de
|
#
6ae9f693 |
|
07-Sep-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Clean up include statements in fbmem.c Remove all unnecessary include statements from fbmem.c. Most of them were for functionality that has meanwhile been moved into other files. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-8-tzimmermann@suse.de
|
#
8887086e |
|
07-Sep-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Move logo functions into separate source file Move the fbdev function for displaying boot-up logos into their own file fb_logo.c. Only build fb_logo.c if CONFIG_LOGO has been selected. No functional changes. v2: * include fb_internal.h (kernel test robot) * simplify option-parsing ifdefs * build fb_logo.o iff CONFIG_LOGO has been set Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-6-tzimmermann@suse.de
|
#
fa671e4f |
|
07-Sep-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Unexport logo helpers The interfaces for the fbdev logo are not used outside of the fbdev module. Hence declare the fbdev logo functions in the internal header file and remove their symbol exports. Only build the functions if CONFIG_LOGO has been selected. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-5-tzimmermann@suse.de
|
#
58d2ef9c |
|
07-Sep-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Fix style of code for boot-up logo Fix a number of warnings from checkpatch.pl in this code before moving it into a separate file. This includes * Prefer 'unsigned int' to bare use of 'unsigned' * space required after that ',' (ctx:VxV) * space prohibited after that open parenthesis '(' * suspect code indent for conditional statements (16, 32) * braces {} are not necessary for single statement blocks No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-4-tzimmermann@suse.de
|
#
ff8fbcf6 |
|
13-Jun-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Rework fb init code Init the class "graphics" before the rest of fbdev. Later steps, such as the sysfs code, depend on the class. Also arrange the module's exit code in reverse order. Unexport the global variable fb_class, which is only shared internally within the fbdev core module. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-38-tzimmermann@suse.de
|
#
588b3563 |
|
13-Jun-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Move file-I/O code into separate file Move fbdev's file-I/O code into a separate file and contain it in init and cleanup helpers. No functional changes. v3: * add missing file fb_chrdev.c v2: * rename source file (Sam) * include <linux/compat.h> (Javier, kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-37-tzimmermann@suse.de
|
#
abcc2f3c |
|
13-Jun-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Move procfs code to separate file Move fbdev's procfs code into a separate file and contain it in init and cleanup helpers. For the cleanup, replace remove_proc_entry() with proc_remove(). It is equivalent in functionality, but looks more like an inverse of proc_create_seq(). v2: * document proc_remove() usage (Sam) * revert unrelated removal of for_each_registered_fb() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-36-tzimmermann@suse.de
|
#
e2af0032 |
|
13-Jun-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Add fb_device_{create,destroy}() Move the logic to create and destroy fbdev devices into the new helpers fb_device_create() and fb_device_destroy(). There was a call to fb_cleanup_device() in do_unregister_framebuffer() that was too late. The device had already been removed at this point. Move the call into fb_device_destroy(). Declare the helpers in the new internal header file fb_internal.h, as they are only used within the fbdev core module. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-35-tzimmermann@suse.de
|
#
403f0dda |
|
13-Jun-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Pass Linux device to pm_vt_switch_*() functions Pass the Linux device to pm_vt_switch_*() instead of the virtual fbdev device. Prepares fbdev for making struct fb_info.dev optional. The type of device that is passed to the PM functions does not matter much. It is only a token within the internal list of known devices. The PM functions do not refer to any of the device's properties or its type. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: linux-pm@vger.kernel.org Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-33-tzimmermann@suse.de
|
#
19abb458 |
|
16-May-2023 |
Arnd Bergmann <arnd@arndb.de> |
fbdev: fbmem: mark get_fb_unmapped_area() static There is a global function with this name on sparc, but no global declaration: drivers/video/fbdev/core/fbmem.c:1469:15: error: no previous prototype for 'get_fb_unmapped_area' Make the generic definition static to avoid this warning. On sparc, this is never seen. Edit by Helge: Update Kconfig text as suggested by Geert Uytterhoeven. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Helge Deller <deller@gmx.de>
|
#
8ff1541d |
|
11-May-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Include <linux/fb.h> instead of <asm/fb.h> Replace include statements for <asm/fb.h> with <linux/fb.h>. Fixes the coding style: if a header is available in asm/ and linux/, it is preferable to include the header from linux/. This only affects a few source files, most of which already include <linux/fb.h>. Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230512102444.5438-6-tzimmermann@suse.de
|
#
6121cd9e |
|
28-Apr-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Move I/O read and write code into helper functions Move the existing I/O read and write code for I/O memory into the new helpers fb_cfb_read() and fb_cfb_write(). Make them the default fp_ops. No functional changes. In the near term, the new functions will be useful to the DRM subsystem, which currently provides it's own implementation. It can then use the shared code. In the longer term, it might make sense to revise the I/O helper's default status and make them opt-in by the driver. Systems that don't use them would not contain the code any longer. v2: * add detailed commit message (Javier) * rename fb_cfb_() to fb_io_() (Geert) * add fixes that got lost while moving the code (Geert) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-19-tzimmermann@suse.de
|
#
3f8974f6 |
|
28-Apr-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Validate info->screen_{base, buffer} in fb_ops implementations Push the test for info->screen_base from fb_read() and fb_write() into the implementations of struct fb_ops.{fb_read,fb_write}. In cases where the driver operates on info->screen_buffer, test this field instead. While bothi fields, screen_base and screen_buffer, are stored in the same location, they refer to different address spaces. For correctness, we want to test each field in exactly the code that uses it. v2: * also test screen_base in pvr2fb (Geert) * also test screen_buffer in ivtvfb, arcfb, broadsheetfb, hecubafb, metronomefb and ssd1307fb (Geert) * give a rational for the change (Geert) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-18-tzimmermann@suse.de
|
#
921b7383 |
|
28-Apr-2023 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Return number of bytes read or written Always return the number of bytes read or written within the framebuffer. Only return an errno code if framebuffer memory was not touched. This is the semantics required by POSIX and makes fb_read() and fb_write() compatible with IGT tests. [1] This bug has been fixed for fb_write() long ago by commit 6a2a88668e90 ("[PATCH] fbdev: Fix return error of fb_write"). The code in fb_read() and the corresponding fb_sys_() helpers was forgotten. It can happen that copy_{from, to}_user() only partially copies the given buffer. Take this into account when calculating the number of bytes. v2: * consider return value from copy_{from,to}_user() (Geert) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Helge Deller <deller@gmx.de> Link: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/fbdev.c # 1 Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-15-tzimmermann@suse.de
|
#
1aaba11d |
|
13-Mar-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
driver core: class: remove module * from class_create() The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6fd33a33 |
|
04-Apr-2023 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace This is an oversight from dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore") - I failed to realize that nasty userspace could set this. It's not pretty to mix up kernel-internal and userspace uapi flags like this, but since the entire fb_var_screeninfo structure is uapi we'd need to either add a new parameter to the ->fb_set_par callback and fb_set_par() function, which has a _lot_ of users. Or some other fairly ugly side-channel int fb_info. Neither is a pretty prospect. Instead just correct the issue at hand by filtering out this kernel-internal flag in the ioctl handling code. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore") Cc: Alex Deucher <alexander.deucher@amd.com> Cc: shlomo@fastmail.com Cc: Michel Dänzer <michel@daenzer.net> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.7+ Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Qiujun Huang <hqjagain@gmail.com> Cc: Peter Rosin <peda@axentia.se> Cc: linux-fbdev@vger.kernel.org Cc: Helge Deller <deller@gmx.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Shigeru Yoshida <syoshida@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404193934.472457-1-daniel.vetter@ffwll.ch
|
#
5b6373de |
|
19-Dec-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/fbdev: Remove aperture handling and FBINFO_MISC_FIRMWARE There are no users left of struct fb_info.apertures and the flag FBINFO_MISC_FIRMWARE. Remove both and the aperture-ownership code in the fbdev core. All code for aperture ownership is now located in the fbdev drivers. 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-19-tzimmermann@suse.de
|
#
3efc61d9 |
|
29-Jan-2023 |
Takashi Iwai <tiwai@suse.de> |
fbdev: Fix invalid page access after closing deferred I/O devices When a fbdev with deferred I/O is once opened and closed, the dirty pages still remain queued in the pageref list, and eventually later those may be processed in the delayed work. This may lead to a corruption of pages, hitting an Oops. This patch makes sure to cancel the delayed work and clean up the pageref list at closing the device for addressing the bug. A part of the cleanup code is factored out as a new helper function that is called from the common fb_release(). Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Miko Larsson <mikoxyzzz@gmail.com> Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230129082856.22113-1-tiwai@suse.de
|
#
0ba2fa8c |
|
11-Nov-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Add support for the nomodeset kernel parameter Support the kernel's nomodeset parameter for all PCI-based fbdev drivers that use aperture helpers to remove other, hardware-agnostic graphics drivers. The parameter is a simple way of using the firmware-provided scanout buffer if the hardware's native driver is broken. The same effect could be achieved with per-driver options, but the importance of the graphics output for many users makes a single, unified approach worthwhile. With nomodeset specified, the fbdev driver module will not load. This unifies behavior with similar DRM drivers. In DRM helpers, modules first check the nomodeset parameter before registering the PCI driver. As fbdev has no such module helpers, we have to modify each driver individually. The name 'nomodeset' is slightly misleading, but has been chosen for historical reasons. Several drivers implemented it before it became a general option for DRM. So keeping the existing name was preferred over introducing a new one. v2: * print a warning if a driver does not init (Helge) * wrap video_firmware_drivers_only() in helper Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221111133024.9897-3-tzimmermann@suse.de
|
#
5727dcfd |
|
25-Jul-2022 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: Make registered_fb[] private to fbmem.c No driver access this anymore, except for the olpc dcon fbdev driver but that has been marked as broken anyways by commit de0952f267ff ("staging: olpc_dcon: mark driver as broken"). 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> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220725075400.68478-1-javierm@redhat.com
|
#
15fced5b |
|
18-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Remove conflict-handling code Remove the call to do_remove_conflicting_framebuffers() from the framebuffer registration. Aperture helpers take care of removing conflicting devices. With all ownership information stored in the aperture datastrcutures, remove remove_conflicting_framebuffers() entirely. This change also rectifies DRM generic-framebuffer registration, which tried to unregister conflicting framebuffers, even though it's entirely build on top of DRM. v2: * remove internal aperture-overlap helpers, which are now unused 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-12-tzimmermann@suse.de
|
#
72a6a3e0 |
|
18-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Acquire framebuffer apertures for firmware devices When registering a generic framebuffer, automatically acquire ownership of the framebuffer's I/O range. The device will now be handled by the aperture helpers. Fbdev-based conflict handling is no longer required. v2: * use fb_ prefix instead of fbm_ (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-11-tzimmermann@suse.de
|
#
4652905f |
|
18-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
video: Provide constants for VGA I/O range Provide VGA_FB_ constants for the VGA framebuffer I/O range and convert fbdev code. In the case of vga16fb, this is a rename of the existing constants VGA_FB_PHYS and VGA_FB_PHYS_LEN. v2: * clarify relationship with old constants in vga16fb (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-9-tzimmermann@suse.de
|
#
5e013761 |
|
18-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
video/aperture: Disable and unregister sysfb devices via aperture helpers Call sysfb_disable() before removing conflicting devices in aperture helpers. Fixes sysfb state if fbdev has been disabled. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: fb84efa28a48 ("drm/aperture: Run fbdev removal before internal helpers") Cc: Zack Rusin <zackr@vmware.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Helge Deller <deller@gmx.de> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Changcheng Deng <deng.changcheng@zte.com.cn> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220718072322.8927-8-tzimmermann@suse.de
|
#
9d69ef18 |
|
18-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Remove remove_conflicting_pci_framebuffers() Remove remove_conflicting_pci_framebuffers() and implement similar functionality in aperture_remove_conflicting_pci_device(), which was the only caller. Removes an otherwise unused interface and streamlines the aperture helper. No functional changes. 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-5-tzimmermann@suse.de
|
#
873eb3b1 |
|
07-Jun-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: Disable sysfb device registration when removing conflicting FBs The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. 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-4-javierm@redhat.com
|
#
3367aa7d |
|
11-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: Restart conflicting fb removal loop when unregistering devices Drivers that want to remove registered conflicting framebuffers prior to register their own framebuffer, call to remove_conflicting_framebuffers(). This function takes the registration_lock mutex, to prevent a race when drivers register framebuffer devices. But if a conflicting framebuffer device is found, the underlaying platform device is unregistered and this will lead to the platform driver .remove callback to be called. Which in turn will call to unregister_framebuffer() that takes the same lock. To prevent this, a struct fb_info.forced_out field was used as indication to unregister_framebuffer() whether the mutex has to be grabbed or not. But this could be unsafe, since the fbdev core is making assumptions about what drivers may or may not do in their .remove callbacks. Allowing to run these callbacks with the registration_lock held can cause deadlocks, since the fbdev core has no control over what drivers do in their removal path. A better solution is to drop the lock before platform_device_unregister(), so unregister_framebuffer() can take it when called from the fbdev driver. The lock is acquired again after the device has been unregistered and at this point the removal loop can be restarted. Since the conflicting framebuffer device has already been removed, the loop would just finish when no more conflicting framebuffers are found. 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/20220511113039.1252432-1-javierm@redhat.com
|
#
6c11df58 |
|
29-Jun-2022 |
Helge Deller <deller@gmx.de> |
fbmem: Check virtual screen sizes in fb_set_var() Verify that the fbdev or drm driver correctly adjusted the virtual screen sizes. On failure report the failing driver and reject the screen size change. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+
|
#
e64242ca |
|
25-Jun-2022 |
Helge Deller <deller@gmx.de> |
fbcon: Prevent that screen size is smaller than font size We need to prevent that users configure a screen size which is smaller than the currently selected font size. Otherwise rendering chars on the screen will access memory outside the graphics memory region. This patch adds a new function fbcon_modechange_possible() which implements this check and which later may be extended with other checks if necessary. The new function is called from the FBIOPUT_VSCREENINFO ioctl handler in fbmem.c, which will return -EINVAL if userspace asked for a too small screen size. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+
|
#
955f0476 |
|
28-Jun-2022 |
Guiling Deng <greens9@163.com> |
fbdev: fbmem: Fix logo center image dx issue Image.dx gets wrong value because of missing '()'. If xres == logo->width and n == 1, image.dx = -16. Signed-off-by: Guiling Deng <greens9@163.com> Fixes: 3d8b1933eb1c ("fbdev: fbmem: add config option to center the bootup logo") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Helge Deller <deller@gmx.de>
|
#
ee7a69aa |
|
07-Jun-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: Disable sysfb device registration when removing conflicting FBs The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. 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-4-javierm@redhat.com
|
#
26817fb7 |
|
04-May-2022 |
Alex Deucher <alexander.deucher@amd.com> |
Revert "fbdev: fbmem: add a helper to determine if an aperture is used by a fw fb" This reverts commit 9a45ac2320d0a6ae01880a30d4b86025fce4061b. This was added a helper for amdgpu to workaround a runtime pm regression caused by a runtime pm fix in efifb. We now have a better workaround in amdgpu in commit f95af4a9236695 ("drm/amdgpu: don't runtime suspend if there are displays attached (v3)") so this workaround is no longer necessary. Since amdgpu was the only user of this interface, we can remove it. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
59055851 |
|
28-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Put mmap for deferred I/O into drivers The fbdev mmap function fb_mmap() unconditionally overrides the driver's implementation if deferred I/O has been activated. This makes it hard to implement mmap with anything but a vmalloc()'ed software buffer. That is specifically a problem for DRM, where video memory is maintained by a memory manager. Leave the mmap handling to drivers and expect them to call the helper for deferred I/O by thmeselves. v4: * unlock mm_lock in fb_mmap() error path (Dan) v3: * fix warning if fb_mmap is missing (kernel test robot) v2: * print a helpful error message if the defio setup is incorrect (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-2-tzimmermann@suse.de
|
#
b76ecff8 |
|
18-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Warn in hot-unplug workaround for framebuffers without device A workaround makes fbdev hot-unplugging work for framebuffers without device. The only user for this feature was offb. As each OF framebuffer now has an associated platform device, the workaround hould no longer be triggered. Update it with a warning and rewrite the comment. Fbdev drivers that trigger the hot-unplug workaround really need to be fixed. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419100405.12600-3-tzimmermann@suse.de
|
#
cabfa2bb |
|
14-Apr-2022 |
Helge Deller <deller@gmx.de> |
Revert "video: fbdev: fbmem: fix pointer reference to null device field" This reverts commit d6cd978f7e6b6f6895f8d0c4ce6e5d2c8e979afe. It has been solved differently already. Signed-off-by: Helge Deller <deller@gmx.de> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220210065824.368355-1-zhouzhouyi@gmail.com
|
#
d6cd978f |
|
09-Feb-2022 |
Zhouyi Zhou <zhouzhouyi@gmail.com> |
video: fbdev: fbmem: fix pointer reference to null device field In function do_remove_conflicting_framebuffers, if device is NULL, there will be null pointer reference. The patch add a check to the if expression. Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220210065824.368355-1-zhouzhouyi@gmail.com
|
#
6e7da3af |
|
05-Apr-2022 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: Move console_lock for register/unlink/unregister 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 <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Du Cheng <ducheng2@gmail.com> Cc: Claudio Suarez <cssk@net-c.es> 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 <sam@ravnborg.org> Cc: Zheyu Ma <zheyuma97@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-15-daniel.vetter@ffwll.ch
|
#
04933a29 |
|
05-Apr-2022 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: use lock_fb_info in fbcon_open/release 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 <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Claudio Suarez <cssk@net-c.es> 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 <ducheng2@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: William Kucharski <william.kucharski@oracle.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Zheyu Ma <zheyuma97@gmail.com> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-13-daniel.vetter@ffwll.ch
|
#
135332f3 |
|
04-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered" This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit attempted to fix a NULL pointer dereference, caused by the struct fb_info associated with a framebuffer device to not longer be valid when the file descriptor was closed. The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"), which added a new path that goes through the struct device removal instead of directly unregistering the fb. Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. This meant that due to this switch, the fb_info was now destroyed too early, while references still existed, while before it was simply leaked. The patch we're reverting here reinstated that leak, hence "fixed" the regression. But the proper solution is to fix the drivers to not release the fb_info too soon. 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/20220504115917.758787-1-javierm@redhat.com
|
#
aafa025c |
|
02-May-2022 |
Javier Martinez Canillas <javierm@redhat.com> |
fbdev: Make fb_release() return -ENODEV if fbdev was unregistered A reference to the framebuffer device struct fb_info is stored in the file private data, but this reference could no longer be valid and must not be accessed directly. Instead, the file_fb_info() accessor function must be used since it does sanity checking to make sure that the fb_info is valid. This can happen for example if the registered framebuffer device is for a driver that just uses a framebuffer provided by the system firmware. In that case, the fbdev core would unregister the framebuffer device when a real video driver is probed and ask to remove conflicting framebuffers. The bug has been present for a long time but commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") unmasked it since the fbdev core started unregistering the framebuffers' devices associated. Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") Reported-by: Maxime Ripard <maxime@cerno.tech> Reported-by: Junxiao Chang <junxiao.chang@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220502135014.377945-1-javierm@redhat.com
|
#
0f525289 |
|
04-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Fix unregistering of framebuffers without device OF framebuffers do not have an underlying device in the Linux device hierarchy. Do a regular unregister call instead of hot unplugging such a non-existing device. Fixes a NULL dereference. An example error message on ppc64le is shown below. BUG: Kernel NULL pointer dereference on read at 0x00000060 Faulting instruction address: 0xc00000000080dfa4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1 NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365) MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28228282 XER: 20000000 CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000 GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000 GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80 GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0 GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0 NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable) [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] [...] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"). Most firmware framebuffers have an underlying platform device, which can be hot-unplugged before loading the native graphics driver. OF framebuffers do not (yet) have that device. Fix the code by unregistering the framebuffer as before without a hot unplug. Tested with 5.17 on qemu ppc64le emulation. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Cc: Zack Rusin <zackr@vmware.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org # v5.11+ Cc: Helge Deller <deller@gmx.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Zheyu Ma <zheyuma97@gmail.com> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Cc: Guenter Roeck <linux@roeck-us.net> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1] Link: https://patchwork.freedesktop.org/patch/msgid/20220404194402.29974-1-tzimmermann@suse.de
|
#
27599aac |
|
25-Jan-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Hot-unplug firmware fb devices on forced removal Hot-unplug all firmware-framebuffer devices as part of removing them via remove_conflicting_framebuffers() et al. Releases all memory regions to be acquired by native drivers. Firmware, such as EFI, install a framebuffer while posting the computer. After removing the firmware-framebuffer device from fbdev, a native driver takes over the hardware and the firmware framebuffer becomes invalid. Firmware-framebuffer drivers, specifically simplefb, don't release their device from Linux' device hierarchy. It still owns the firmware framebuffer and blocks the native drivers from loading. This has been observed in the vmwgfx driver. [1] Initiating a device removal (i.e., hot unplug) as part of remove_conflicting_framebuffers() removes the underlying device and returns the memory range to the system. [1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-zack@kde.org/ v2: * rename variable 'dev' to 'device' (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Zack Rusin <zackr@vmware.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> CC: stable@vger.kernel.org # v5.11+ Link: https://patchwork.freedesktop.org/patch/msgid/20220125091222.21457-2-tzimmermann@suse.de
|
#
0a786596 |
|
28-Oct-2021 |
Changcheng Deng <deng.changcheng@zte.com.cn> |
video: fbmem: use swap() to make code cleaner in fb_rotate_logo() Use swap() in order to make code cleaner. Issue found by coccinelle. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn> Signed-off-by: Helge Deller <deller@gmx.de>
|
#
68e8cc2a |
|
02-Feb-2022 |
Yizhuo Zhai <yzhai003@ucr.edu> |
fbdev: fbmem: Fix the implicit type casting In function do_fb_ioctl(), the "arg" is the type of unsigned long, and in "case FBIOBLANK:" this argument is casted into an int before passig to fb_blank(). In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would be bypass if the original "arg" is a large number, which is possible because it comes from the user input. Fix this by adding the check before the function call. Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Helge Deller <deller@gmx.de> Signed-off-by: Yizhuo Zhai <yzhai003@ucr.edu> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220202235811.1621017-1-yzhai003@ucr.edu
|
#
9a45ac23 |
|
22-Dec-2021 |
Alex Deucher <alexander.deucher@amd.com> |
fbdev: fbmem: add a helper to determine if an aperture is used by a fw fb Add a function for drivers to check if the a firmware initialized fb is corresponds to their aperture. This allows drivers to check if the device corresponds to what the firmware set up as the display device. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215203 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1840 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
#
2c0c19b6 |
|
10-Oct-2021 |
Zheyu Ma <zheyuma97@gmail.com> |
fbdev: fbmem: Fix double free of 'fb_info->pixmap.addr' savagefb and some other drivers call kfree to free 'info->pixmap.addr' even after calling unregister_framebuffer, which may cause double free. Fix this by setting 'fb_info->pixmap.addr' to NULL after kfree in unregister_framebuffer. The following log reveals it: [ 37.318872] BUG: KASAN: double-free or invalid-free in kfree+0x13e/0x290 [ 37.319369] [ 37.320803] Call Trace: [ 37.320992] dump_stack_lvl+0xa8/0xd1 [ 37.321274] print_address_description+0x87/0x3b0 [ 37.321632] ? kfree+0x13e/0x290 [ 37.321879] ? kfree+0x13e/0x290 [ 37.322126] ? kfree+0x13e/0x290 [ 37.322374] kasan_report_invalid_free+0x58/0x90 [ 37.322724] ____kasan_slab_free+0x123/0x140 [ 37.323049] __kasan_slab_free+0x11/0x20 [ 37.323347] slab_free_freelist_hook+0x81/0x150 [ 37.323689] ? savagefb_remove+0xa1/0xc0 [savagefb] [ 37.324066] kfree+0x13e/0x290 [ 37.324304] savagefb_remove+0xa1/0xc0 [savagefb] [ 37.324655] pci_device_remove+0xa9/0x250 [ 37.324959] ? pci_device_probe+0x7d0/0x7d0 [ 37.325273] device_release_driver_internal+0x4f7/0x7a0 [ 37.325666] driver_detach+0x1e8/0x2c0 [ 37.325952] bus_remove_driver+0x134/0x290 [ 37.326262] ? sysfs_remove_groups+0x97/0xb0 [ 37.326584] driver_unregister+0x77/0xa0 [ 37.326883] pci_unregister_driver+0x2c/0x1c0 [ 37.336124] [ 37.336245] Allocated by task 5465: [ 37.336507] ____kasan_kmalloc+0xb5/0xe0 [ 37.336801] __kasan_kmalloc+0x9/0x10 [ 37.337069] kmem_cache_alloc_trace+0x12b/0x220 [ 37.337405] register_framebuffer+0x3f3/0xa00 [ 37.337731] foo_register_framebuffer+0x3b/0x50 [savagefb] [ 37.338136] [ 37.338255] Freed by task 5475: [ 37.338492] kasan_set_track+0x3d/0x70 [ 37.338774] kasan_set_free_info+0x23/0x40 [ 37.339081] ____kasan_slab_free+0x10b/0x140 [ 37.339399] __kasan_slab_free+0x11/0x20 [ 37.339694] slab_free_freelist_hook+0x81/0x150 [ 37.340034] kfree+0x13e/0x290 [ 37.340267] do_unregister_framebuffer+0x21c/0x3d0 [ 37.340624] unregister_framebuffer+0x23/0x40 [ 37.340950] savagefb_remove+0x45/0xc0 [savagefb] [ 37.341302] pci_device_remove+0xa9/0x250 [ 37.341603] device_release_driver_internal+0x4f7/0x7a0 [ 37.341990] driver_detach+0x1e8/0x2c0 [ 37.342272] bus_remove_driver+0x134/0x290 [ 37.342577] driver_unregister+0x77/0xa0 [ 37.342873] pci_unregister_driver+0x2c/0x1c0 [ 37.343196] cleanup_module+0x15/0x1c [savagefb] [ 37.343543] __se_sys_delete_module+0x398/0x490 [ 37.343881] __x64_sys_delete_module+0x56/0x60 [ 37.344221] do_syscall_64+0x4d/0xc0 [ 37.344492] entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1633848148-29747-1-git-send-email-zheyuma97@gmail.com
|
#
8c28051c |
|
08-Sep-2021 |
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> |
fbmem: don't allow too huge resolutions syzbot is reporting page fault at vga16fb_fillrect() [1], for vga16fb_check_var() is failing to detect multiplication overflow. if (vxres * vyres > maxmem) { vyres = maxmem / vxres; if (vyres < yres) return -ENOMEM; } Since no module would accept too huge resolutions where multiplication overflow happens, let's reject in the common path. Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1] Reported-by: syzbot <syzbot+04168c8063cfdde1db5e@syzkaller.appspotmail.com> Debugged-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp
|
#
0189cb57 |
|
18-Jul-2021 |
Xiyu Yang <xiyuyang19@fudan.edu.cn> |
fbmem: Convert from atomic_t to refcount_t on fb_info->count refcount_t type and corresponding API can protect refcounters from accidental underflow and overflow and further use-after-free situations. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1626674392-55857-1-git-send-email-xiyuyang19@fudan.edu.cn
|
#
0af77826 |
|
12-Jul-2021 |
Zhen Lei <thunder.leizhen@huawei.com> |
fbmem: Do not delete the mode that is still in use The execution of fb_delete_videomode() is not based on the result of the previous fbcon_mode_deleted(). As a result, the mode is directly deleted, regardless of whether it is still in use, which may cause UAF. ================================================================== BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Read of size 4 at addr ffff88807e0ddb1c by task syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ... Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 18960: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422 slab_free_hook mm/slub.c:1541 [inline] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [inline] kfree+0xca/0x3d0 mm/slub.c:4121 fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 13ff178ccd6d ("fbcon: Call fbcon_mode_deleted/new_modelist directly") Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Cc: <stable@vger.kernel.org> # v5.3+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712085544.2828-1-thunder.leizhen@huawei.com
|
#
0b78f8bc |
|
01-Jun-2021 |
Matthew Wilcox <willy@infradead.org> |
Revert "fb_defio: Remove custom address_space_operations" Commit ccf953d8f3d6 makes framebuffers which use deferred I/O stop displaying updates after the first one. This is because the pages handled by fb_defio no longer have a page_mapping(). That prevents page_mkclean() from marking the PTEs as clean, and so writes are only noticed the first time. Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/YLZEhv0cpZp8uVE3@casper.infradead.org
|
#
6dae40ae |
|
09-May-2021 |
Linus Torvalds <torvalds@linux-foundation.org> |
fbmem: fix horribly incorrect placement of __maybe_unused Commit b9d79e4ca4ff ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
b9d79e4c |
|
04-May-2021 |
Guenter Roeck <linux@roeck-us.net> |
fbmem: Mark proc_fb_seq_ops as __maybe_unused With CONFIG_PROC_FS=n and -Werror, 0-day reports: drivers/video/fbdev/core/fbmem.c:736:36: error: 'proc_fb_seq_ops' defined but not used Mark it as __maybe_unused. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210504142910.2084722-1-linux@roeck-us.net
|
#
ccf953d8 |
|
10-Mar-2021 |
Matthew Wilcox (Oracle) <willy@infradead.org> |
fb_defio: Remove custom address_space_operations There's no need to give the page an address_space. Leaving the page->mapping as NULL will cause the VM to handle set_page_dirty() the same way that it's handled now, and that was the only reason to set the address_space in the first place. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: William Kucharski <william.kucharski@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210310185530.1053320-1-willy@infradead.org
|
#
23d6ab1d |
|
05-Nov-2020 |
Jason Gunthorpe <jgg@ziepe.ca> |
drm: remove pgprot_decrypted() before calls to io_remap_pfn_range() commit f8f6ae5d077a ("mm: always have io_remap_pfn_range() set pgprot_decrypted()") moves the pgprot_decrypted() into io_remap_pfn_range(). Delete any, now confusing, open coded calls that directly precede io_remap_pfn_range(): - drm_io_prot() is only in drm_mmap_locked() to call io_remap_pfn_range() - fb_mmap() immediately calls vm_iomap_memory() which is a convenience wrapper for io_remap_pfn_range() Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-2e6a0db57868+166-drm_sme_clean_jgg@nvidia.com
|
#
06f42774 |
|
17-Sep-2020 |
Arnd Bergmann <arnd@arndb.de> |
fbdev: simplify fb_getput_cmap() This function is one of the remaining users of compat_alloc_user_space() and copy_in_user(). Clean it up by copying to a local data structure copy instead, which also leads to more readable code. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200918100926.1447563-1-arnd@arndb.de
|
#
a49145ac |
|
07-Jul-2020 |
George Kennedy <george.kennedy@oracle.com> |
fbmem: add margin check to fb_check_caps() A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting or yres setting in struct fb_var_screeninfo will result in a KASAN: vmalloc-out-of-bounds failure in bitfill_aligned() as the margins are being cleared. The margins are cleared in chunks and if the xres setting or yres setting is a value of zero upto the chunk size, the failure will occur. Add a margin check to validate xres and yres settings. Signed-off-by: George Kennedy <george.kennedy@oracle.com> Reported-by: syzbot+e5fd3e65515b48c02a30@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dhaval Giani <dhaval.giani@oracle.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1594149963-13801-1-git-send-email-george.kennedy@oracle.com
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
d88ca7e1 |
|
30-Jul-2020 |
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> |
fbmem: pull fbcon_update_vcs() out of fb_set_var() syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy() based on outdated old_{rows,row_size} values, for resize_screen() can recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates old_{rows,row_size} values which were saved before calling resize_screen(). Daniel Vetter explained that resize_screen() should not recurse into fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set when calling resize_screen(). Instead of masking FBINFO_MISC_USEREVENT before calling fbcon_update_vcs(), we can remove FBINFO_MISC_USEREVENT by calling fbcon_update_vcs() only if fb_set_var() returned 0. This change assumes that it is harmless to call fbcon_update_vcs() when fb_set_var() returned 0 without reaching fb_notifier_call_chain(). [1] https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e Reported-and-tested-by: syzbot <syzbot+c37a14770d51a085a520@syzkaller.appspotmail.com> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: kernel test robot <lkp@intel.com> for missing #include Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/075b7e37-3278-cd7d-31ab-c5073cfa8e92@i-love.sakura.ne.jp
|
#
ad04fae0 |
|
07-Jul-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
fbdev: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200707210539.GA12530@embeddedor
|
#
2d05f56a |
|
29-Jul-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Remove trailing whitespace Removes trailing whitespaces in several places. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200729134148.6855-2-tzimmermann@suse.de
|
#
93166f5f |
|
17-Dec-2019 |
Nathan Chancellor <nathan@kernel.org> |
fbmem: Adjust indentation in fb_prepare_logo and fb_blank Clang warns: ../drivers/video/fbdev/core/fbmem.c:665:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] if (fb_logo.depth > 4 && depth > 4) { ^ ../drivers/video/fbdev/core/fbmem.c:661:2: note: previous statement is here else ^ ../drivers/video/fbdev/core/fbmem.c:1075:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] return ret; ^ ../drivers/video/fbdev/core/fbmem.c:1072:2: note: previous statement is here if (!ret) ^ 2 warnings generated. This warning occurs because there are spaces before the tabs on these lines. Normalize the indentation in these functions so that it is consistent with the Linux kernel coding style and clang no longer warns. Fixes: 1692b37c99d5 ("fbdev: Fix logo if logo depth is less than framebuffer depth") Link: https://github.com/ClangBuiltLinux/linux/issues/825 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218030025.10064-1-natechancellor@gmail.com
|
#
d3d19d6f |
|
13-Jan-2020 |
Dan Carpenter <dan.carpenter@oracle.com> |
fbdev: potential information leak in do_fb_ioctl() The "fix" struct has a 2 byte hole after ->ywrapstep and the "fix = info->fix;" assignment doesn't necessarily clear it. It depends on the compiler. The solution is just to replace the assignment with an memcpy(). Fixes: 1f5e31d7e55a ("fbmem: don't call copy_from/to_user() with mutex held") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrea Righi <righi.andrea@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Peter Rosin <peda@axentia.se> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200113100132.ixpaymordi24n3av@kili.mountain
|
#
ab1c4c5e |
|
27-Aug-2019 |
Peter Rosin <peda@axentia.se> |
fbdev: fbmem: avoid exporting fb_center_logo The variable is only ever used from fbcon.c which is linked into the same module. Therefore, the export is not needed. Signed-off-by: Peter Rosin <peda@axentia.se> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827110854.12574-4-peda@axentia.se
|
#
691f50ab |
|
27-Aug-2019 |
Peter Rosin <peda@axentia.se> |
fbdev: fbmem: allow overriding the number of bootup logos Probably most useful if you want no logo at all, or if you only want one logo regardless of how many CPU cores you have. Signed-off-by: Peter Rosin <peda@axentia.se> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827110854.12574-3-peda@axentia.se
|
#
f23c57e2 |
|
28-Nov-2019 |
Jani Nikula <jani.nikula@intel.com> |
video: fbmem: use const pointer for fb_ops Use const for fb_ops to let us make the info->fbops pointer const in the future. v2: rebase 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/3a27f95b424a67b3542b5906c660741daf1d4ea6.1575022735.git.jani.nikula@intel.com
|
#
12281c8d |
|
28-Nov-2019 |
Jani Nikula <jani.nikula@intel.com> |
video: fb_defio: preserve user fb_ops Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap and then resetting it to NULL afterwards causes problems all over the place. First, it prevents making the fbops member of struct fb_info a const pointer, which means we can't make struct fb_ops const anywhere. Second, a few places have to go out of their way to restore the original fb_mmap pointer that gets reset to NULL. Since the only user of the fbops->fb_mmap hook is fb_mmap() in fbmem.c, call fb_deferred_io_mmap() directly when deferred IO is enabled, and avoid modifying fb_ops altogether. Simply use info->fbdefio to determine whether deferred IO should be used or not. This should be accurate enough for all use cases, although perhaps not pedantically correct. v2: Simplify considerably by calling fb_deferred_io_mmap() directly (Daniel, Ville) Cc: Jaya Kumar <jayalk@intworks.biz> Cc: linux-fbdev@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Noralf Trønnes <noralf@tronnes.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/022c82429da15d6450ff9ac1a897322ec3124db4.1575022735.git.jani.nikula@intel.com
|
#
f597c208 |
|
14-Nov-2019 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev: Unexport unlink_framebuffer() There are no external callers of unlink_framebuffer() left. Make the function an internal interface. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191114125106.28347-4-tzimmermann@suse.de
|
#
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_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/
|
#
0a845969 |
|
22-Aug-2019 |
Gerd Hoffmann <kraxel@redhat.com> |
fbdev: drop res_id parameter from remove_conflicting_pci_framebuffers Since commit b0e999c95581 ("fbdev: list all pci memory bars as conflicting apertures") the parameter was used for some sanity checks only, to make sure we detect any issues with the new approach to just list all memory bars as apertures. No issues turned up so far, so continue to cleanup: Drop the res_id parameter, drop the sanity checks. Also downgrade the logging from "info" level to "debug" level and update documentation. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20190822090645.25410-2-kraxel@redhat.com
|
#
e7642f35 |
|
25-Jul-2019 |
Sam Ravnborg <sam@ravnborg.org> |
backlight: drop EARLY_EVENT_BLANK support There was no users left - so drop the code to support EARLY_EVENT_BLANK. This patch removes the support in backlight, and drop the notifier in fbmem. That EARLY_EVENT_BLANK is not used can be verified that no driver set any of: lcd_ops.early_set_power() lcd_ops.r_early_set_power() Noticed while browsing backlight code for other reasons. v2: - Fix changelog to say "EARLY_EVENT_BLANK" (Daniel) Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190725143224.GB31803@ravnborg.org
|
#
a74cefd9 |
|
24-Jun-2019 |
Colin Ian King <colin.king@canonical.com> |
fbmem: remove redundant assignment to err Variable err is initialized to a value that is never read and it is re-assigned later. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190624223724.13629-1-colin.king@canonical.com
|
#
fe2d70d6 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: Call con2fb_map functions directly These are actually fbcon ioctls which just happen to be exposed through /dev/fb*. They completely ignore which fb_info they're called on, and I think the userspace tool even hardcodes to /dev/fb0. Hence just forward the entire thing to fbcon.c wholesale. Note that this patch drops the fb_lock/unlock on the set side. Since the ioctl can operate on any fb (as passed in through con2fb.framebuffer) this is bogus. Also note that fbcon.c in general never calls fb_lock on anything, so this has been badly broken already. With this the last user of the fbcon notifier callback is gone, and we can garbage collect that too. v2: add missing uaccess.h include (alpha fails to compile otherwise), reported by kbuild. v3: Remember to also drop the #defines (Maarten) v4: Add the static inline to dummy functions. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Mikulas Patocka <mpatocka@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-31-daniel.vetter@ffwll.ch
|
#
9e146700 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls Create a new wrapper function for this, feels like there's some refactoring room here between the two modes. v2: backlight notifier is also interested in the mode change event, it calls lcd->set_mode, of which there are 3 implementations. Thanks to Maarten for spotting this. So we keep that. We can ditch the differentiation between mode change and all mode changes (because backlight notifier doesn't care), and we can drop the FBINFO_MISC_USEREVENT stuff too, because that's just to prevent recursion between fbmem.c and fbcon.c. While at it flatten the control flow a bit. v3: Need to add a static inline to the dummy function. v4: Add missing #include <fbcon.h> to sh_mob (Sam). Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-29-daniel.vetter@ffwll.ch
|
#
c428f35a |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fb: Flatten control flow in fb_set_var Instead of wiring almost everything down to the very last line using goto soup (but not consistently, where would the fun be otherwise) drop out early when checks fail. This allows us to flatten the huge indent levels to just 1. Aside: If a driver doesn't set ->fb_check_var, then FB_ACTIVATE_NOW does nothing. This bug exists ever since this code was extracted as a common helper in 2002, hence I decided against fixing it. Everyone just better have a fb_check_var to make sure things work correctly. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-28-daniel.vetter@ffwll.ch
|
#
36676173 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: remove FBINFO_MISC_USEREVENT around fb_blank With the recursion broken in the previous patch we can drop the FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion prevention was it's only job. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-27-daniel.vetter@ffwll.ch
|
#
de29ae5c |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbmem: pull fbcon_fb_blanked out of fb_blank There's a callchain of: fbcon_fb_blanked -> do_(un)blank_screen -> consw->con_blank -> fbcon_blank -> fb_blank Things don't go horribly wrong because the BKL console_lock safes the day, but that's about it. And the seeming recursion is broken in 2 ways: - Starting from the fbdev ioctl we set FBINFO_MISC_USEREVENT, which tells the fbcon_blank code to not call fb_blank. This was required to not deadlock when recursing on the fb_notifier_chain mutex. - Starting from the con_blank hook we're getting saved by the console_blanked checks in do_blank/unblank_screen. Or at least that's my theory. Anyway, recursion isn't awesome, so let's stop it. Breaking the recursion avoids the need to be in the FBINFO_MISC_USEREVENT critical section, so lets move it out of that too. The astute reader will notice that fb_blank seems to require lock_fb_info(), which the fbcon code seems to ignore. I have no idea how to fix that problem, so let's keep ignoring it. v2: I forgot the sysfs blanking code. v3: Fix typo in callchain in the commmit message (Sam). Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-26-daniel.vetter@ffwll.ch
|
#
7a625549 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928. The justification is that if hw blanking fails (i.e. fbops->fb_blank) fails, then we still want to shut down the backlight. Which is exactly _not_ what fb_blank() does and so rather inconsistent if we end up with different behaviour between fbcon and direct fbdev usage. Given that the entire notifier maze is getting in the way anyway I figured it's simplest to revert this not well justified commit. v2: Add static inline to the dummy version. Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Daniel Thompson <daniel.thompson@linaro.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-25-daniel.vetter@ffwll.ch
|
#
0526c223 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: Call fbcon_get_requirement directly Pretty simple case really. v2: Forgot to remove a break; v3: Add static inline to the dummy versions. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-24-daniel.vetter@ffwll.ch
|
#
13ff178c |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: Call fbcon_mode_deleted/new_modelist directly I'm not entirely clear on what new_modelist actually does, it seems exclusively for a sysfs interface. Which in the end does amount to a normal fb_set_par to check the mode, but then takes a different path in both fbmem.c and fbcon.c. I have no idea why these 2 paths are different, but then I also don't really want to find out. So just do the simple conversion to a direct function call. v2: static inline for the dummy versions, I forgot. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Peter Rosin <peda@axentia.se> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-23-daniel.vetter@ffwll.ch
|
#
50c50563 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: directly call fbcon_suspended/resumed With the sh_mobile notifier removed we can just directly call the fbcon code here. v2: Remove now unused local variable. v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Konstantin Khorenko <khorenko@virtuozzo.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-22-daniel.vetter@ffwll.ch
|
#
927ab1ae |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: unify unlink_framebuffer paths For some reasons the pm_vt_switch_unregister call was missing from the direct unregister_framebuffer path. Fix this. v2: fbinfo->dev is used to decided whether unlink_framebuffer has been called already. I botched that in v1. Make this all clearer by inlining __unlink_framebuffer. v3: Fix typoe in subject (Maarten). Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-20-daniel.vetter@ffwll.ch
|
#
deb00d27 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: make unregister/unlink functions not fail Except for driver bugs (which we'll catch with a WARN_ON) this is only to report failures of the new driver taking over the console. There's nothing the outgoing driver can do about that, and no one ever bothered to actually look at these return values. So remove them all. v2: fixup unregister_framebuffer in savagefb, fbtft, ivtvfb, and neofb drivers, reported by kbuild. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-19-daniel.vetter@ffwll.ch
|
#
0e0f3250 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: call fbcon_fb_bind directly Also remove the error return value. That's all errors for either driver bugs (trying to unbind something that isn't bound), or errors of the new driver that will take over. There's nothing the outgoing driver can do about this anyway, so switch over to void. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Peter Rosin <peda@axentia.se> Cc: Kees Cook <keescook@chromium.org> Cc: Konstantin Khorenko <khorenko@virtuozzo.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-18-daniel.vetter@ffwll.ch
|
#
cf4a3ae4 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: lock_fb_info cannot fail Ever since commit c47747fde931c02455683bd00ea43eaa62f35b0e Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed May 11 14:58:34 2011 -0700 fbmem: make read/write/ioctl use the frame buffer at open time fbdev has gained proper refcounting for the fbinfo attached to any open files, which means that the backing driver (stored in fb_info->fbops) cannot untimely disappear anymore. The only thing that can happen is that the entire device just outright disappears and gets unregistered, but file_fb_info does check for that. Except that it's racy - it only checks once at the start of a file_ops, there's no guarantee that the underlying fbdev won't untimely disappear. Aside: A proper way to fix that race is probably to replicate the srcu trickery we've rolled out in drm. But given that this race has existed since forever it's probably not one we need to fix right away. do_unregister_framebuffer also nowhere clears fb_info->fbops, hence the check in lock_fb_info can't possible catch a disappearing fbdev later on. Long story short: Ever since the above commit the fb_info->fbops checks have essentially become dead code. Remove this all. Aside from the file_ops callbacks, and stuff called from there there's only register/unregister code left. If that goes wrong a driver managed to register/unregister a device instance twice or in the wrong order. That's just a driver bug. v2: - fb_mmap had an open-coded version of the fbinfo->fops check, because it doesn't need the fbinfo->lock. Delete that too. - Use the wrapper function in fb_open/release now, since no difference anymore. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Peter Rosin <peda@axentia.se> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-17-daniel.vetter@ffwll.ch
|
#
97b67986 |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: call fbcon_fb_(un)registered directly With commit 6104c37094e729f3d4ce65797002112735d49cd1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev we have a static dependency between fbcon and fbdev, and we can replace the indirection through the notifier chain with a function call. v2: Sam Ravnborg noticed that mach-pxa/am200epd.c has a notifier too, and listens to this. ... Looking at the code it seems to wait for some fb to show up, so that it can get the framebuffer base address from the fb_info struct. I suspect his is some firmware fbdev. Then it uses that information to let the real fbdev driver (metronomefb.c by the looks) get at the framebuffer memory. This doesn't looke like it's easy to fix (except by deleting the entire thing, seems untouched since 2008, we might be able to get away with that), so let's just stuff a few #ifdef into fb.h and fbmem.c and cry over them for a bit. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: Peter Rosin <peda@axentia.se> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: linux-fbdev@vger.kernel.org Cc: Daniel Mack <daniel@zonque.org> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Konstantin Khorenko <khorenko@virtuozzo.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Steve Sakoman <sakoman@gmail.com> Cc: Steve Sakoman <steve@sakoman.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-11-daniel.vetter@ffwll.ch
|
#
7076404f |
|
28-May-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: locking check for fb_set_suspend Just drive-by, nothing systematic yet. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Kees Cook <keescook@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190528090304.9388-3-daniel.vetter@ffwll.ch
|
#
b0e999c9 |
|
01-Apr-2019 |
Gerd Hoffmann <kraxel@redhat.com> |
fbdev: list all pci memory bars as conflicting apertures Simply add all pci memory bars to struct apertures_struct in remove_conflicting_pci_framebuffers(), without depending on the res_id parameter. The plan is to drop the res_id parameter later on. For now keep the parameter, use it for sanity-checking and warn on inconsistencies. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
a5399db1 |
|
08-Feb-2019 |
Manfred Schlaegl <manfred.schlaegl@ginzinger.com> |
fbdev: fbmem: fix memory access if logo is bigger than the screen There is no clipping on the x or y axis for logos larger that the framebuffer size. Therefore: a logo bigger than screen size leads to invalid memory access: [ 1.254664] Backtrace: [ 1.254728] [<c02714e0>] (cfb_imageblit) from [<c026184c>] (fb_show_logo+0x620/0x684) [ 1.254763] r10:00000003 r9:00027fd8 r8:c6a40000 r7:c6a36e50 r6:00000000 r5:c06b81e4 [ 1.254774] r4:c6a3e800 [ 1.254810] [<c026122c>] (fb_show_logo) from [<c026c1e4>] (fbcon_switch+0x3fc/0x46c) [ 1.254842] r10:c6a3e824 r9:c6a3e800 r8:00000000 r7:c6a0c000 r6:c070b014 r5:c6a3e800 [ 1.254852] r4:c6808c00 [ 1.254889] [<c026bde8>] (fbcon_switch) from [<c029c8f8>] (redraw_screen+0xf0/0x1e8) [ 1.254918] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c070d5a0 r5:00000080 [ 1.254928] r4:c6808c00 [ 1.254961] [<c029c808>] (redraw_screen) from [<c029d264>] (do_bind_con_driver+0x194/0x2e4) [ 1.254991] r9:00000000 r8:00000000 r7:00000014 r6:c070d5a0 r5:c070d5a0 r4:c070d5a0 So prevent displaying a logo bigger than screen size and avoid invalid memory access. Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
890d14d2 |
|
16-Jan-2019 |
Peter Rosin <peda@axentia.se> |
fbdev: fbmem: convert CONFIG_FB_LOGO_CENTER into a cmd line option A command line option is much more flexible than a config option and the supporting code is small. Gets rid of #ifdefs in the code too... Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
3d8b1933 |
|
20-Dec-2018 |
Peter Rosin <peda@axentia.se> |
fbdev: fbmem: add config option to center the bootup logo If there are extra logos (CONFIG_FB_LOGO_EXTRA) the heights of these extra logos are not considered when centering the first logo vertically. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
e41f184d |
|
20-Dec-2018 |
Peter Rosin <peda@axentia.se> |
fbdev: fbmem: make fb_show_logo_line return the end instead of the height In preparation for allowing centering of the bootup logo, make fb_show_logo_line return where the next free framebuffer line is, instead of returning the height of the shown logo. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
f75df8d4 |
|
20-Dec-2018 |
Peter Rosin <peda@axentia.se> |
fbdev: fbmem: behave better with small rotated displays and many CPUs Blitting an image with "negative" offsets is not working since there is no clipping. It hopefully just crashes. For the bootup logo, there is protection so that blitting does not happen as the image is drawn further and further to the right (ROTATE_UR) or further and further down (ROTATE_CW). There is however no protection when drawing in the opposite directions (ROTATE_UD and ROTATE_CCW). Add back this protection. The regression is 20-odd years old but the mindless warning-killing mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove positive test on unsigned values") is also to blame, methinks. Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates") Signed-off-by: Peter Rosin <peda@axentia.se> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Fabian Frederick <ffrederick@users.sourceforge.net> Cc: Geert Uytterhoeven <geert+renesas@glider.be> cc: Geoff Levand <geoff@infradead.org> Cc: James Simmons <jsimmons@users.sf.net> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
da6c7707 |
|
22-Aug-2018 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: Add FBINFO_HIDE_SMEM_START flag DRM drivers really, really, really don't want random userspace to share buffer behind it's back, bypassing the dma-buf buffer sharing machanism. For that reason we've ruthlessly rejected any IOCTL exposing the physical address of any graphics buffer. Unfortunately fbdev comes with that built-in. We could just set smem_start to 0, but that means we'd have to hand-roll our own fb_mmap implementation. For good reasons many drivers do that, but smem_start/length is still super convenient. Hence instead just stop the leak in the ioctl, to keep fb mmap working as-is. A second patch will set this flag for all drm drivers. Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Kees Cook <keescook@chromium.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822085405.10787-3-daniel.vetter@ffwll.ch
|
#
d3147adc |
|
07-Sep-2018 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
fbdev: fix kerneldoc As noticed by kbuild test robot <lkp@intel.com>, remove_conflicting_pci_framebuffers()'s second argument is called res_id not resource_id. Fix this. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/38ca9044455a33e398b45e0281643cc24da3c2fc.1536342224.git.mirq-linux@rere.qmqm.pl
|
#
4d18975c |
|
01-Sep-2018 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
fbdev: add remove_conflicting_pci_framebuffers() Almost all PCI drivers using remove_conflicting_framebuffers() wrap it with the same code. v2: add kerneldoc for DRM helper v3: propagate remove_conflicting_framebuffers() return value + move kerneldoc to where function is implemented Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/7db1c278276de420eb45a1b71d06b5eb6bbd49ef.1535810304.git.mirq-linux@rere.qmqm.pl
|
#
69aa5355 |
|
01-Sep-2018 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
fbdev: add kerneldoc do remove_conflicting_framebuffers() Document remove_conflicting_framebuffers() behaviour. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/283fef19815b991700b56119d8d5874a2a8da44e.1535810304.git.mirq-linux@rere.qmqm.pl
|
#
5fa793d3 |
|
01-Sep-2018 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
fbdev: allow apertures == NULL in remove_conflicting_framebuffers() Interpret (otherwise-invalid) NULL apertures argument to mean all-memory range. This will allow to remove several duplicates of this code from drivers in following patches. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/b5fed539fe569035139c8594c23effd8c39f12ca.1535810304.git.mirq-linux@rere.qmqm.pl
|
#
fbc42d45 |
|
01-Sep-2018 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
fbdev: show fbdev number for debugging Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/ef584ecd8642e8b1a04f28d6d9c1864b5aa507bb.1535810304.git.mirq-linux@rere.qmqm.pl
|
#
3f2ce542 |
|
31-Jul-2018 |
Thomas Zimmermann <tzimmermann@suse.de> |
fbdev/core: Disable console-lock warnings when fb.lockless_register_fb is set If the console is unlocked during registration, the console subsystem generates significant amounts of warnings, which obfuscate actual debugging messages. Setting ignore_console_lock_warning while debugging console registration avoid the noise. v3: - manipulate ignore_console_lock_warning with atomic_{inc,dec} v2: - restore ignore_console_lock_warning if lock_fb_info() fails Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
8c5b0442 |
|
25-Jul-2018 |
Mikulas Patocka <mpatocka@redhat.com> |
fb: fix lost console when the user unplugs a USB adapter I have a USB display adapter using the udlfb driver and I use it on an ARM board that doesn't have any graphics card. When I plug the adapter in, the console is properly displayed, however when I unplug and re-plug the adapter, the console is not displayed and I can't access it until I reboot the board. The reason is this: When the adapter is unplugged, dlfb_usb_disconnect calls unlink_framebuffer, then it waits until the reference count drops to zero and then it deallocates the framebuffer. However, the console that is attached to the framebuffer device keeps the reference count non-zero, so the framebuffer device is never destroyed. When the USB adapter is plugged again, it creates a new device /dev/fb1 and the console is not attached to it. This patch fixes the bug by unbinding the console from unlink_framebuffer. The code to unbind the console is moved from do_unregister_framebuffer to a function unbind_console. When the console is unbound, the reference count drops to zero and the udlfb driver frees the framebuffer. When the adapter is plugged back, a new framebuffer is created and the console is attached to it. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Bernie Thompson <bernie@plugable.com> Cc: Ladislav Michl <ladis@linux-mips.org> Cc: stable@vger.kernel.org [b.zolnierkie: preserve old behavior for do_unregister_framebuffer()] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
810180fc |
|
24-Jul-2018 |
Gustavo A. R. Silva <gustavo@embeddedor.com> |
fbdev: fbmem: mark expected switch fall-through In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
10ac8688 |
|
24-Jul-2018 |
Yisheng Xie <ysxie@foxmail.com> |
fbcon: introduce for_each_registered_fb() helper Following pattern is often used: for (i = 0; i < FB_MAX; i++) { if (registered_fb[i]) { ... } } Therefore, as Andy's suggestion, for_each_registered_fb() helper can be introduced to make the code easier to read and write by reducing indentation level. It also saves few lines of code in each occurrence. This patch convert all part here at the same time. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Yisheng Xie <ysxie@foxmail.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
6da2ec56 |
|
12-Jun-2018 |
Kees Cook <keescook@chromium.org> |
treewide: kmalloc() -> kmalloc_array() The kmalloc() function has a 2-factor argument form, kmalloc_array(). This patch replaces cases of: kmalloc(a * b, gfp) with: kmalloc_array(a * b, gfp) as well as handling cases of: kmalloc(a * b * c, gfp) with: kmalloc(array3_size(a, b, c), gfp) as it's slightly less ugly than: kmalloc_array(array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: kmalloc(4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. The tools/ directory was manually excluded, since it has its own implementation of kmalloc(). The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ type TYPE; expression THING, E; @@ ( kmalloc( - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | kmalloc( - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression COUNT; typedef u8; typedef __u8; @@ ( kmalloc( - sizeof(u8) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(__u8) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(char) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(unsigned char) * (COUNT) + COUNT , ...) | kmalloc( - sizeof(u8) * COUNT + COUNT , ...) | kmalloc( - sizeof(__u8) * COUNT + COUNT , ...) | kmalloc( - sizeof(char) * COUNT + COUNT , ...) | kmalloc( - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - kmalloc + kmalloc_array ( - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ identifier SIZE, COUNT; @@ - kmalloc + kmalloc_array ( - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( kmalloc( - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | kmalloc( - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kmalloc( - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kmalloc( - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | kmalloc( - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( kmalloc( - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kmalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | kmalloc( - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kmalloc( - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | kmalloc( - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | kmalloc( - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ identifier STRIDE, SIZE, COUNT; @@ ( kmalloc( - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | kmalloc( - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression E1, E2, E3; constant C1, C2, C3; @@ ( kmalloc(C1 * C2 * C3, ...) | kmalloc( - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | kmalloc( - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | kmalloc( - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | kmalloc( - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( kmalloc(sizeof(THING) * C2, ...) | kmalloc(sizeof(TYPE) * C2, ...) | kmalloc(C1 * C2 * C3, ...) | kmalloc(C1 * C2, ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - kmalloc + kmalloc_array ( - (E1) * E2 + E1, E2 , ...) | - kmalloc + kmalloc_array ( - (E1) * (E2) + E1, E2 , ...) | - kmalloc + kmalloc_array ( - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
fddda2b7 |
|
13-Apr-2018 |
Christoph Hellwig <hch@lst.de> |
proc: introduce proc_create_seq{,_data} Variants of proc_create{,_data} that directly take a struct seq_operations argument and drastically reduces the boilerplate code in the callers. All trivial callers converted over. Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
16622a8e |
|
18-Aug-2017 |
David Lechner <david@lechnology.com> |
fbdev: fix 1bpp logo for unusual width This check is needed in the case where the width of the framebuffer is not a multiple of 8 pixels. For example, LEGO MINDSTORMS EV3 has a 178x128 1bpp display. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
376b3ff5 |
|
01-Aug-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: Nuke FBINFO_MODULE Instead check info->ops->owner, which amounts to the same. Spotted because I want to remove the pile of broken and cargo-culted fb_info->flags assignments in drm drivers. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
6104c370 |
|
01-Aug-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbcon: Make fbcon a built-time depency for fbdev There's a bunch of folks who're trying to make printk less contended and faster, but there's a problem: printk uses the console_lock, and the console lock has become the BKL for all things fbdev/fbcon, which in turn pulled in half the drm subsystem under that lock. That's awkward. There reasons for that is probably just a historical accident: - fbcon is a runtime option of fbdev, i.e. at runtime you can pick whether your fbdev driver instances are used as kernel consoles. Unfortunately this wasn't implemented with some module option, but through some module loading magic: As long as you don't load fbcon.ko, there's no fbdev console support, but loading it (in any order wrt fbdev drivers) will create console instances for all fbdev drivers. - This was implemented through a notifier chain. fbcon.ko enumerates all fbdev instances at load time and also registers itself as listener in the fbdev notifier. The fbdev core tries to register new fbdev instances with fbcon using the notifier. - On top of that the modifier chain is also used at runtime by the fbdev subsystem to e.g. control backlights for panels. - The problem is that the notifier puts a mutex locking context between fbdev and fbcon, which mixes up the locking contexts for both the runtime usage and the register time usage to notify fbcon. And at runtime fbcon (through the fbdev core) might call into the notifier from a printk critical section while console_lock is held. - This means console_lock must be an outer lock for the entire fbdev subsystem, which also means it must be acquired when registering a new framebuffer driver as the outermost lock since we might call into fbcon (through the notifier) which would result in a locking inversion if fbcon would acquire the console_lock from its notifier callback (which it needs to register the console). - console_lock can be held anywhere, since printk can be called anywhere, and through the above story, plus drm/kms being an fbdev driver, we pull in a shocking amount of locking hiercharchy underneath the console_lock. Which makes cleaning up printk really hard (not even splitting console_lock into an rwsem is all that useful due to this). There's various ways to address this, but the cleanest would be to make fbcon a compile-time option, where fbdev directly calls the fbcon register functions from register_framebuffer, or dummy static inline versions if fbcon is disabled. Maybe augmented with a runtime knob to disable fbcon, if that's needed (for debugging perhaps). But this could break some users who rely on the magic "loading fbcon.ko enables/disables fbdev framebuffers at runtime" thing, even if that's unlikely. Hence we must be careful: 1. Create a compile-time dependency between fbcon and fbdev in the least minimal way. This is what this patch does. 2. Wait at least 1 year to give possible users time to scream about how we broke their setup. Unlikely, since all distros make fbcon compile-in, and embedded platforms only compile stuff they know they need anyway. But still. 3. Convert the notifier to direct functions calls, with dummy static inlines if fbcon is disabled. We'll still need the fb notifier for the other uses (like backlights), but we can probably move it into the fb core (atm it must be built-into vmlinux). 4. Push console_lock down the call-chain, until it is down in console_register again. 5. Finally start to clean up and rework the printk/console locking. For context of this saga see commit 50e244cc793d511b86adea24972f3a7264cae114 Author: Alan Cox <alan@linux.intel.com> Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeover plus the pile of commits on top that tried to make this all work without terminally upsetting lockdep. We've uncovered all this when console_lock lockdep annotations where added in commit daee779718a319ff9f83e1ba3339334ac650bb22 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Sep 22 19:52:11 2012 +0200 console: implement lockdep support for console_lock On the patch itself: - Switch CONFIG_FRAMEBUFFER_CONSOLE to be a boolean, using the overall CONFIG_FB tristate to decided whether it should be a module or built-in. - At first I thought I could force the build depency with just a dummy symbol that fbcon.ko exports and fb.ko uses. But that leads to a module depency cycle (it works fine when built-in). Since this tight binding is the entire goal the simplest solution is to move all the fbcon modules (and there's a bunch of optinal source-files which are each modules of their own, for no good reason) into the overall fb.ko core module. That's a bit more than what I would have liked to do in this patch, but oh well. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
95cf9264 |
|
17-Jul-2017 |
Tom Lendacky <thomas.lendacky@amd.com> |
x86, drm, fbdev: Do not specify encrypted memory for video mappings Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/a19436f30424402e01f63a09b32ab103272acced.1500319216.git.thomas.lendacky@amd.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
4c99ceda |
|
12-Jul-2017 |
Benjamin Gaignard <benjamin.gaignard@linaro.org> |
fbdev: make get_fb_unmapped_area depends of !MMU Even if CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA flag is selected do not compile and use get_fb_unmapped_area() if CONFIG_MMU is also set. This will avoid mmap errors when compiling multi architectures at same time. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
#
9a469037 |
|
26-May-2017 |
Al Viro <viro@zeniv.linux.org.uk> |
fb_get_fscreeninfo(): don't bother with do_fb_ioctl() it's easier to do the right thing directly Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
82f42e4c |
|
04-Jan-2017 |
Benjamin Gaignard <benjamin.gaignard@linaro.org> |
fbmem: add a default get_fb_unmapped_area function Allow generic frame-buffer to provide a default get_fb_unmapped_area function if specific devices need it. Usually this function is defined in architecture directories but define it here may limit code duplication especially for all ARM platforms without MMU. version 5: - set get_unmapped_area field if FB_PROVIDE_GET_FB_UNMAPPED_AREA is defined version 4: - introdude a configuration flag to be independent of architecture Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1483521177-21794-2-git-send-email-benjamin.gaignard@linaro.org
|
#
524edf38 |
|
02-May-2016 |
Alexey Khoroshilov <khoroshilov@ispras.ru> |
fbdev: fbmem: implement error handling in fbmem_init() fbmem_init() ignores all errors, while fbmem_exit() does not check if deallocating resources are valid. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
c3c296b0 |
|
25-Aug-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
fbdev: Debug knob to register without holding console_lock When the usual fbcon legacy options are enabled we have ->register_framebuffer ->fb notifier chain calls into fbcon ->fbcon sets up console on new fbi ->fbi->set_par ->drm_fb_helper_set_par exercises full kms api And because of locking inversion hilarity all of register_framebuffer is done with the console lock held. Which means that the first time on driver load we exercise _all_ the kms code (all probe paths and modeset paths for everything connected) is under the console lock. That means if anything goes belly-up in that big pile of code nothing ever reaches logfiles (and the machine is dead). Usual tactic to debug that is to temporarily remove those console_lock calls to be able to capture backtraces. I'm fed up writing this patch and recompiling kernels. Hence this patch here to add an unsafe, kernel-taining option to do this at runtime. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
ea6763c1 |
|
06-Aug-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
video/fbdev: Always built-in video= cmdline parsing In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract these 2 functions and always build them in. Whiel at it fix the checkpatch fail in this code. v2: Also move fb_mode_option. Spotted by the kbuild. v3: Review from Geert: - Keep the old copyright notice from fb_mem.c, although I have no idea what exactly applies. - Only compile this when needed. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> -- I prefer if we can merge this through drm-next since we'll use it there in follow-up patches. -Daniel
|
#
34bdb666 |
|
25-Apr-2014 |
Fabian Frederick <fabf@skynet.be> |
fbdev: fbmem: remove positive test on unsigned values fb_image.dx, fb_image.dy and fbconf2bmap.framebuffer are __u32 Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
23e51f87 |
|
24-Apr-2014 |
Arnd Bergmann <arnd@arndb.de> |
video: export fb_prepare_logo Some drivers that may be loadable modules use the fb_prepare_logo function, so we have to export it. Found during randconfig builds with mmpfb. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
#
19757fc8 |
|
13-Feb-2014 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
fbdev: move fbdev core files to separate directory Instead of having fbdev framework core files at the root fbdev directory, mixed with random fbdev device drivers, move the fbdev core files to a separate core directory. This makes it much clearer which of the files are actually part of the fbdev framework, and which are part of device drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|