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

fbdev: Remove FBINFO_DEFAULT from framebuffer_alloc()'ed structs

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

The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Cc: Helge Deller Cc: Nicolas Ferre Cc: Benjamin Herrenschmidt Cc: Ferenc Bakonyi Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Wei Liu Cc: Dexuan Cui Cc: Antonino Daplas Cc: Maik Broemme Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Kristoffer Ericson Cc: Hans de Goede Cc: Steve Glendinning Cc: Bernie Thompson Cc: Florian Tobias Schandinat Link: https://patchwork.freedesktop.org/patch/msgid/20230715185343.7193-6-tzimmermann@suse.de

Backmerge tag 'v6.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next

2023-06-19T06:01:25+00:00

Linux 6.4-rc7 Need this to pull in the msm work. Signed-off-by: Dave Airlie

fbdev: udlfb: Use usb_control_msg_send()

2023-05-20T19:12:07+00:00

Use the newly introduced usb_control_msg_send() instead of usb_control_msg() when selecting the channel. Reviewed-by: Alan Stern Signed-off-by: Helge Deller

fbdev: udlfb: Fix endpoint check

2023-05-20T05:02:13+00:00

The syzbot fuzzer detected a problem in the udlfb driver, caused by an endpoint not having the expected type: usb 1-1: Read EDID byte 0 failed: -71 usb 1-1: Unable to get valid EDID from device/display ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980 dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315 dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111 dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743 The current approach for this issue failed to catch the problem because it only checks for the existence of a bulk-OUT endpoint; it doesn't check whether this endpoint is the one that the driver will actually use. We can fix the problem by instead checking that the endpoint used by the driver does exist and is bulk-OUT. Reported-and-tested-by: syzbot+0e22d63dcebb802b9bc8@syzkaller.appspotmail.com Signed-off-by: Alan Stern CC: Pavel Skripkin Fixes: aaf7dbe07385 ("video: fbdev: udlfb: properly check endpoint type") Signed-off-by: Helge Deller

fbdev/udlfb: Use struct fb_info.screen_buffer

2023-05-08T13:28:33+00:00

Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-12-tzimmermann@suse.de

fbdev: udlfb: Remove redundant initialization to variable identical

2022-10-08T13:20:08+00:00

The variable identical is being initialized with a value that is never read. The variable is being re-assigned later on. The initialization is redundant and can be removed. Cleans up clang scan-build warning: drivers/video/fbdev/udlfb.c:373:6: warning: Value stored to 'identical' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King Signed-off-by: Helge Deller

fbdev: Use pageref offset for deferred-I/O writeback

2022-05-03T14:04:22+00:00

Use pageref->offset instead of page->index for deferred-I/O writeback where appropriate. Distinguishes between file-mapping offset and video- memory offset. While at it, also remove unnecessary references to struct page. Fbdev's deferred-I/O code uses the two related page->index and pageref->offset. The former is the page offset in the mapped file, the latter is the byte offset in the video memory (or fbdev screen buffer). It's the same value for fbdev drivers, but for DRM the values can be different. Because GEM buffer objects are mapped at an offset in the DRM device file, page->index has this offset added to it as well. We currently don't hit this case in DRM, because all affected mappings of GEM memory are performed with an internal, intermediate shadow buffer. The value of page->index is required by page_mkclean(), which we call to reset the mappings during the writeback phase of the deferred I/O. The value of pageref->offset is for conveniently getting an offset into video memory in fb helpers. v4: * fix commit message (Javier) Suggested-by: Javier Martinez Canillas Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-6-tzimmermann@suse.de

fbdev: Rename pagelist to pagereflist for deferred I/O

2022-05-03T14:04:22+00:00

Rename various instances of pagelist to pagereflist. The list now stores pageref structures, so the new name is more appropriate. In their write-back helpers, several fbdev drivers refer to the pageref list in struct fb_deferred_io instead of using the one supplied as argument to the function. Convert them over to the supplied one. It's the same instance, so no change of behavior occurs. v4: * fix commit message (Javier) Suggested-by: Sam Ravnborg Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-5-tzimmermann@suse.de

fbdev: Track deferred-I/O pages in pageref struct

2022-05-03T14:04:22+00:00

Store the per-page state for fbdev's deferred I/O in struct fb_deferred_io_pageref. Maintain a list of pagerefs for the pages that have to be written back to video memory. Update all affected drivers. As with pages before, fbdev acquires a pageref when an mmaped page of the framebuffer is being written to. It holds the pageref in a list of all currently written pagerefs until it flushes the written pages to video memory. Writeback occurs periodically. After writeback fbdev releases all pagerefs and builds up a new dirty list until the next writeback occurs. Using pagerefs has a number of benefits. For pages of the framebuffer, the deferred I/O code used struct page.lru as an entry into the list of dirty pages. The lru field is owned by the page cache, which makes deferred I/O incompatible with some memory pages (e.g., most notably DRM's GEM SHMEM allocator). struct fb_deferred_io_pageref now provides an entry into a list of dirty framebuffer pages, freeing lru for use with the page cache. Drivers also assumed that struct page.index is the page offset into the framebuffer. This is not true for DRM buffers, which are located at various offset within a mapped area. struct fb_deferred_io_pageref explicitly stores an offset into the framebuffer. struct page.index is now only the page offset into the mapped area. These changes will allow DRM to use fbdev deferred I/O without an intermediate shadow buffer. v3: * use pageref->offset for sorting * fix grammar in comment v2: * minor fixes in commit message Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-3-tzimmermann@suse.de

fbdev: Put mmap for deferred I/O into drivers

2022-05-03T14:04:21+00:00

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