user/sven/linux.git/include/linux/fb.h, branch v6.2.7

fbdev: Fix invalid page access after closing deferred I/O devices

2023-02-10T10:03:37Z

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 Cc: Signed-off-by: Takashi Iwai Tested-by: Miko Larsson Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Reviewed-by: Thomas Zimmermann Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230129082856.22113-1-tiwai@suse.de

Merge tag 'drm-misc-next-fixes-2022-12-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2022-12-09T01:53:52Z

Some deferred-io and damage worker reworks revert and make a fb function static Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20221208084040.yw4zavsjd25qsltf@houat

Backmerge tag 'v6.1-rc6' into drm-next

2022-11-24T01:05:43Z

Linux 6.1-rc6 This is needed for drm-misc-next and tegra. Signed-off-by: Dave Airlie

Revert "drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer"

2022-11-23T08:11:00Z

This reverts commit 7f5cc4a3e5e4c5a38e5748defc952e45278f7a70. Needed to restore the fbdev damage worker. There have been bug reports about locking order [1] and incorrectly takens branches. [2] Restore the damage worker until these problems have been resovled. Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Link: https://intel-gfx-ci.01.org/tree/drm-tip/fi-kbl-8809g.html # 1 Link: https://lore.kernel.org/dri-devel/20221115115819.23088-6-tzimmermann@suse.de/T/#m06eedc0a468940e4cbbd14ca026733b639bc445a # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20221118133535.9739-3-tzimmermann@suse.de (cherry picked from commit 8b83e1a455382dc667898a525a93f4eb6716cc41)

fbdev: Make fb_modesetting_disabled() static inline

2022-11-23T08:09:40Z

Make fb_modesetting_disabled() a static-inline function when it is defined in the header file. Avoid the linker error shown below. ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled': fbmon.c:(.text+0x1e4): multiple definition of `fb_modesetting_disabled'; drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here A bug report is at [1]. Reported-by: Stephen Rothwell Reported-by: kernel test robot Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Fixes: 0ba2fa8cbd29 ("fbdev: Add support for the nomodeset kernel parameter") Cc: Javier Martinez Canillas Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/dri-devel/20221117183214.2473e745@canb.auug.org.au/T/#u # 1 Link: https://patchwork.freedesktop.org/patch/msgid/20221117114729.7570-1-tzimmermann@suse.de (cherry picked from commit a189b2ee938f6b15ad9f95bdef63f95a3a092418)

fbdev: Add support for the nomodeset kernel parameter

2022-11-16T12:26:25Z

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

drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer

2022-11-16T12:22:24Z

Schedule the deferred-I/O worker instead of the damage worker after writing to the fbdev framebuffer. The deferred-I/O worker then performs the dirty-fb update. The fbdev emulation will initialize deferred I/O for all drivers that require damage updates. It is therefore a valid assumption that the deferred-I/O worker is present. It would be possible to perform the damage handling directly from within the write operation. But doing this could increase the overhead of the write or interfere with a concurrently scheduled deferred-I/O worker. Instead, scheduling the deferred-I/O worker with its regular delay of 50 ms removes load off the write operation and allows the deferred-I/O worker to handle multiple write operations that arrived during the delay time window. v3: * remove unused variable (lkp) v2: * keep drm_fb_helper_damage() (Daniel) * use fb_deferred_io_schedule_flush() (Daniel) * clarify comments (Daniel) Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-6-tzimmermann@suse.de

fbdev: MIPS supports iomem addresses

2022-10-17T11:49:45Z

Add MIPS to fb_* helpers list for iomem addresses. This silences Sparse warnings about lacking __iomem address space casts: drivers/video/fbdev/pvr2fb.c:800:9: sparse: sparse: incorrect type in argument 1 (different address spaces) drivers/video/fbdev/pvr2fb.c:800:9: sparse: expected void const * drivers/video/fbdev/pvr2fb.c:800:9: sparse: got char [noderef] __iomem *screen_base Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/202210100209.tR2Iqbqk-lkp@intel.com/ Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kees Cook Signed-off-by: Helge Deller

fbdev: Make registered_fb[] private to fbmem.c

2022-07-27T07:40:18Z

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 Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Signed-off-by: Javier Martinez Canillas Signed-off-by: Thomas Zimmermann Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220725075400.68478-1-javierm@redhat.com

fbdev: Remove conflict-handling code

2022-07-19T11:19:11Z

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