summaryrefslogtreecommitdiff
path: root/drivers/video
AgeCommit message (Collapse)Author
2025-06-27fbcon: Make sure modelist not set on unregistered consoleKees Cook
[ Upstream commit cedc1b63394a866bf8663a3e40f4546f1d28c8d8 ] It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Reported-by: syzbot+a7d4444e7b6e743572f7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/679d0a8f.050a0220.163cdc.000c.GAE@google.com/ Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27dummycon: Trigger redraw when switching consoles with deferred takeoverThomas Zimmermann
commit 03bcbbb3995ba5df43af9aba45334e35f2dfe27b upstream. Signal vt subsystem to redraw console when switching to dummycon with deferred takeover enabled. Makes the console switch to fbcon and displays the available output. With deferred takeover enabled, dummycon acts as the placeholder until the first output to the console happens. At that point, fbcon takes over. If the output happens while dummycon is not active, it cannot inform fbcon. This is the case if the vt subsystem runs in graphics mode. A typical graphical boot starts plymouth, a display manager and a compositor; all while leaving out dummycon. Switching to a text-mode console leaves the console with dummycon even if a getty terminal has been started. Returning true from dummycon's con_switch helper signals the vt subsystem to redraw the screen. If there's output available dummycon's con_putc{s} helpers trigger deferred takeover of fbcon, which sets a display mode and displays the output. If no output is available, dummycon remains active. v2: - make the comment slightly more verbose (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Andrei Borzenkov <arvidjaar@gmail.com> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191 Tested-by: Andrei Borzenkov <arvidjaar@gmail.com> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover") Cc: Hans de Goede <hdegoede@redhat.com> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.19+ Link: https://lore.kernel.org/r/20250520071418.8462-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27video: screen_info: Relocate framebuffers behind PCI bridgesThomas Zimmermann
commit 2f29b5c231011b94007d2c8a6d793992f2275db1 upstream. Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reported-by: "Ivan T. Ivanov" <iivanov@suse.de> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1240696 Tested-by: "Ivan T. Ivanov" <iivanov@suse.de> Fixes: 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.9+ Link: https://lore.kernel.org/r/20250528080234.7380-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27vgacon: Add check for vc_origin address range in vgacon_scroll()GONG Ruiqi
commit 864f9963ec6b4b76d104d595ba28110b87158003 upstream. Our in-house Syzkaller reported the following BUG (twice), which we believed was the same issue with [1]: ================================================================== BUG: KASAN: slab-out-of-bounds in vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 Read of size 2 at addr ffff88800f5bef60 by task syz.7.2620/12393 ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description.constprop.0+0x6b/0x3d0 mm/kasan/report.c:364 print_report+0xba/0x280 mm/kasan/report.c:475 kasan_report+0xa9/0xe0 mm/kasan/report.c:588 vcs_scr_readw+0xc2/0xd0 drivers/tty/vt/vt.c:4740 vcs_write_buf_noattr drivers/tty/vt/vc_screen.c:493 [inline] vcs_write+0x586/0x840 drivers/tty/vt/vc_screen.c:690 vfs_write+0x219/0x960 fs/read_write.c:584 ksys_write+0x12e/0x260 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 ... </TASK> Allocated by task 5614: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0x8f/0xa0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:201 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x62/0x140 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] vc_do_resize+0x235/0xf40 drivers/tty/vt/vt.c:1193 vgacon_adjust_height+0x2d4/0x350 drivers/video/console/vgacon.c:1007 vgacon_font_set+0x1f7/0x240 drivers/video/console/vgacon.c:1031 con_font_set drivers/tty/vt/vt.c:4628 [inline] con_font_op+0x4da/0xa20 drivers/tty/vt/vt.c:4675 vt_k_ioctl+0xa10/0xb30 drivers/tty/vt/vt_ioctl.c:474 vt_ioctl+0x14c/0x1870 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x655/0x1510 drivers/tty/tty_io.c:2779 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 __fput_sync+0x4c/0x60 fs/file_table.c:465 __do_sys_close fs/open.c:1580 [inline] __se_sys_close+0x68/0xd0 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 __kasan_record_aux_stack+0x94/0xa0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0xc3/0xa10 kernel/rcu/tree.c:2713 netlink_release+0x620/0xc20 net/netlink/af_netlink.c:802 __sock_release+0xb5/0x270 net/socket.c:663 sock_close+0x1e/0x30 net/socket.c:1425 __fput+0x408/0xab0 fs/file_table.c:384 task_work_run+0x154/0x240 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:45 [inline] do_exit+0x8e5/0x1320 kernel/exit.c:874 do_group_exit+0xcd/0x280 kernel/exit.c:1023 get_signal+0x1675/0x1850 kernel/signal.c:2905 arch_do_signal_or_restart+0x80/0x3b0 arch/x86/kernel/signal.c:310 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x1b3/0x1e0 kernel/entry/common.c:218 do_syscall_64+0x66/0x110 arch/x86/entry/common.c:87 entry_SYSCALL_64_after_hwframe+0x78/0xe2 The buggy address belongs to the object at ffff88800f5be000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 2656 bytes to the right of allocated 1280-byte region [ffff88800f5be000, ffff88800f5be500) ... Memory state around the buggy address: ffff88800f5bee00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bee80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88800f5bef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88800f5bef80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800f5bf000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== By analyzing the vmcore, we found that vc->vc_origin was somehow placed one line prior to vc->vc_screenbuf when vc was in KD_TEXT mode, and further writings to /dev/vcs caused out-of-bounds reads (and writes right after) in vcs_write_buf_noattr(). Our further experiments show that in most cases, vc->vc_origin equals to vga_vram_base when the console is in KD_TEXT mode, and it's around vc->vc_screenbuf for the KD_GRAPHICS mode. But via triggerring a TIOCL_SETVESABLANK ioctl beforehand, we can make vc->vc_origin be around vc->vc_screenbuf while the console is in KD_TEXT mode, and then by writing the special 'ESC M' control sequence to the tty certain times (depends on the value of `vc->state.y - vc->vc_top`), we can eventually move vc->vc_origin prior to vc->vc_screenbuf. Here's the PoC, tested on QEMU: ``` int main() { const int RI_NUM = 10; // should be greater than `vc->state.y - vc->vc_top` int tty_fd, vcs_fd; const char *tty_path = "/dev/tty0"; const char *vcs_path = "/dev/vcs"; const char escape_seq[] = "\x1bM"; // ESC + M const char trigger_seq[] = "Let's trigger an OOB write."; struct vt_sizes vt_size = { 70, 2 }; int blank = TIOCL_BLANKSCREEN; tty_fd = open(tty_path, O_RDWR); char vesa_mode[] = { TIOCL_SETVESABLANK, 1 }; ioctl(tty_fd, TIOCLINUX, vesa_mode); ioctl(tty_fd, TIOCLINUX, &blank); ioctl(tty_fd, VT_RESIZE, &vt_size); for (int i = 0; i < RI_NUM; ++i) write(tty_fd, escape_seq, sizeof(escape_seq) - 1); vcs_fd = open(vcs_path, O_RDWR); write(vcs_fd, trigger_seq, sizeof(trigger_seq)); close(vcs_fd); close(tty_fd); return 0; } ``` To solve this problem, add an address range validation check in vgacon_scroll(), ensuring vc->vc_origin never precedes vc_screenbuf. Reported-by: syzbot+9c09fda97a1a65ea859b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9c09fda97a1a65ea859b [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Co-developed-by: Yi Yang <yiyang13@huawei.com> Signed-off-by: Yi Yang <yiyang13@huawei.com> Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varMurad Masimov
commit 05f6e183879d9785a3cdf2f08a498bc31b7a20aa upstream. If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in ↵Murad Masimov
fb_videomode_to_var commit 17186f1f90d34fa701e4f14e6818305151637b9e upstream. If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - "This should not happen" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Murad Masimov <m.masimov@mt-integration.ru> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19backlight: pm8941: Add NULL check in wled_configure()Henry Martin
[ Upstream commit e12d3e1624a02706cdd3628bbf5668827214fa33 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: "Daniel Thompson (RISCstar)" <danielt@kernel.org> Link: https://lore.kernel.org/r/20250401091647.22784-1-bsdhenrymartin@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()Sergey Shtylyov
[ Upstream commit 3f6dae09fc8c306eb70fdfef70726e1f154e173a ] In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Fixes: 96fe6a2109db ("[PATCH] fbdev: Add VESA Coordinated Video Timings (CVT) support") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29fbdev: core: tileblit: Implement missing margin clearing for tileblitZsolt Kajtar
[ Upstream commit 76d3ca89981354e1f85a3e0ad9ac4217d351cc72 ] I was wondering why there's garbage at the bottom of the screen when tile blitting is used with an odd mode like 1080, 600 or 200. Sure there's only space for half a tile but the same area is clean when the buffer is bitmap. Then later I found that it's supposed to be cleaned but that's not implemented. So I took what's in bitblit and adapted it for tileblit. This implementation was tested for both the horizontal and vertical case, and now does the same as what's done for bitmap buffers. If anyone is interested to reproduce the problem then I could bet that'd be on a S3 or Ark. Just set up a mode with an odd line count and make sure that the virtual size covers the complete tile at the bottom. E.g. for 600 lines that's 608 virtual lines for a 16 tall tile. Then the bottom area should be cleaned. For the right side it's more difficult as there the drivers won't let an odd size happen, unless the code is modified. But once it reports back a few pixel columns short then fbcon won't use the last column. With the patch that column is now clean. Btw. the virtual size should be rounded up by the driver for both axes (not only the horizontal) so that it's dividable by the tile size. That's a driver bug but correcting it is not in scope for this patch. Implement missing margin clearing for tileblit Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29fbcon: Use correct erase colour for clearing in fbconZsolt Kajtar
[ Upstream commit 892c788d73fe4a94337ed092cb998c49fa8ecaf4 ] The erase colour calculation for fbcon clearing should use get_color instead of attr_col_ec, like everything else. The latter is similar but is not correct. For example it's missing the depth dependent remapping and doesn't care about blanking. The problem can be reproduced by setting up the background colour to grey (vt.color=0x70) and having an fbcon console set to 2bpp (4 shades of gray). Now the background attribute should be 1 (dark gray) on the console. If the screen is scrolled when pressing enter in a shell prompt at the bottom line then the new line is cleared using colour 7 instead of 1. That's not something fillrect likes (at 2bbp it expect 0-3) so the result is interesting. This patch switches to get_color with vc_video_erase_char to determine the erase colour from attr_col_ec. That makes the latter function redundant as no other users were left. Use correct erase colour for clearing in fbcon Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29fbdev: fsl-diu-fb: add missing device_remove_file()Shixiong Ou
[ Upstream commit 86d16cd12efa547ed43d16ba7a782c1251c80ea8 ] Call device_remove_file() when driver remove. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-20backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Herve Codina
commit 276822a00db3c1061382b41e72cafc09d6a0ec30 upstream. Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable(). Fixes: ae232e45acf9 ("backlight: add led-backlight driver") Cc: stable@vger.kernel.org Signed-off-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20250122091914.309533-1-herve.codina@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-04-20fbdev: omapfb: Add 'plane' value checkLeonid Arapov
[ Upstream commit 3e411827f31db7f938a30a3c7a7599839401ec30 ] Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB of the enum parameter plane. The value of this parameter is initialized in dss_init_overlays and in the current state of the code it cannot take this value so it's not a real problem. For the purposes of defensive coding it wouldn't be superfluous to check the parameter value, because some functions down the call stack process this value correctly and some not. For example, in dispc_ovl_setup_global_alpha it may lead to buffer overflow. Add check for this value. Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool. Signed-off-by: Leonid Arapov <arapovl839@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10fbdev: sm501fb: Add some geometry checks.Danila Chernetsov
[ Upstream commit aee50bd88ea5fde1ff4cc021385598f81a65830c ] Added checks for xoffset, yoffset settings. Incorrect settings of these parameters can lead to errors in sm501fb_pan_ functions. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5fc404e47bdf ("[PATCH] fb: SM501 framebuffer driver") Signed-off-by: Danila Chernetsov <listdansp@mail.ru> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10mdacon: rework dependency listArnd Bergmann
[ Upstream commit 5bbcc7645f4b244ffb5ac6563fbe9d3d42194447 ] mdacon has roughly the same dependencies as vgacon but expresses them as a negative list instead of a positive list, with the only practical difference being PowerPC/CHRP, which uses vga16fb instead of vgacon. The CONFIG_MDA_CONSOLE description advises to only turn it on when vgacon is also used because MDA/Hercules-only systems should be using vgacon instead, so just change the list to enforce that directly for simplicity. The probing was broken from 2002 to 2008, this improves on the fix that was added then: If vgacon is a loadable module, then mdacon cannot be built-in now, and the list of systems that support vgacon is carried over. Fixes: 0b9cf3aa6b1e ("mdacon messing up default vc's - set default to vc13-16 again") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10dummycon: fix default rows/colsArnd Bergmann
[ Upstream commit beefaba1978c04ea2950d34236f58fe6cf6a7f58 ] dummycon fails to build on ARM/footbridge when the VGA console is disabled, since I got the dependencies slightly wrong in a previous patch: drivers/video/console/dummycon.c: In function 'dummycon_init': drivers/video/console/dummycon.c:27:25: error: 'CONFIG_DUMMY_CONSOLE_COLUMNS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 27 | #define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS drivers/video/console/dummycon.c:28:25: error: 'CONFIG_DUMMY_CONSOLE_ROWS' undeclared (first use in this function); did you mean 'CONFIG_DUMMY_CONSOLE'? 28 | #define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS This only showed up after many thousand randconfig builds on Arm, and doesn't matter in practice, but should still be fixed. Address it by using the default row/columns on footbridge after all in that corner case. Fixes: 4293b0925149 ("dummycon: limit Arm console size hack to footbridge") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202409151512.LML1slol-lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10fbdev: au1100fb: Move a variable assignment behind a null pointer checkMarkus Elfring
[ Upstream commit 2df2c0caaecfd869b49e14f2b8df822397c5dd7f ] The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “au1100fb_setmode”. This issue was detected by using the Coccinelle software. Fixes: 3b495f2bb749 ("Au1100 FB driver uplift for 2.6.") Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-22fbdev: hyperv_fb: Allow graceful removal of framebufferSaurabh Sengar
[ Upstream commit ea2f45ab0e53b255f72c85ccd99e2b394fc5fceb ] When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released. [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290] <TASK> [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0 Fix this by moving the release of framebuffer and assosiated memory to fb_ops.fb_destroy function, so that framebuffer framework handles it gracefully. While we fix this, also replace manual registrations/unregistration of framebuffer with devm_register_framebuffer. Fixes: 68a2d20b79b1 ("drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver") Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1740845791-19977-3-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1740845791-19977-3-git-send-email-ssengar@linux.microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-22fbdev: hyperv_fb: Simplify hvfb_putmemSaurabh Sengar
[ Upstream commit f5e728a50bb17336a20803dde488515b833ecd1d ] The device object required in 'hvfb_release_phymem' function for 'dma_free_coherent' can also be obtained from the 'info' pointer, making 'hdev' parameter in 'hvfb_putmem' redundant. Remove the unnecessary 'hdev' argument from 'hvfb_putmem'. Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1740845791-19977-2-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1740845791-19977-2-git-send-email-ssengar@linux.microsoft.com> Stable-dep-of: ea2f45ab0e53 ("fbdev: hyperv_fb: Allow graceful removal of framebuffer") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-22fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMsMichael Kelley
[ Upstream commit 304386373007aaca9236a3f36afac0bbedcd2bf0 ] Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer device. When the kdump kernel runs in such a VM, loading the efifb driver may hang because of accessing the framebuffer at the wrong memory address. The scenario occurs when the hyperv_fb driver in the original kernel moves the framebuffer to a different MMIO address because of conflicts with an already-running efifb or simplefb driver. The hyperv_fb driver then informs Hyper-V of the change, which is allowed by the Hyper-V FB VMBus device protocol. However, when the kexec command loads the kdump kernel into crash memory via the kexec_file_load() system call, the system call doesn't know the framebuffer has moved, and it sets up the kdump screen_info using the original framebuffer address. The transition to the kdump kernel does not go through the Hyper-V host, so Hyper-V does not reset the framebuffer address like it would do on a reboot. When efifb tries to run, it accesses a non-existent framebuffer address, which traps to the Hyper-V host. After many such accesses, the Hyper-V host thinks the guest is being malicious, and throttles the guest to the point that it runs very slowly or appears to have hung. When the kdump kernel is loaded into crash memory via the kexec_load() system call, the problem does not occur. In this case, the kexec command builds the screen_info table itself in user space from data returned by the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the new framebuffer location. This problem was originally reported in 2020 [1], resulting in commit 3cb73bc3fa2a ("hyperv_fb: Update screen_info after removing old framebuffer"). This commit solved the problem by setting orig_video_isVGA to 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb driver did not try to load, and no hang occurred. But in 2024, commit c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info") effectively reverted 3cb73bc3fa2a. Commit c25a19afb81c has no reference to 3cb73bc3fa2a, so perhaps it was done without knowing the implications that were reported with 3cb73bc3fa2a. In any case, as of commit c25a19afb81c, the original problem came back again. Interestingly, the hyperv_drm driver does not have this problem because it never moves the framebuffer. The difference is that the hyperv_drm driver removes any conflicting framebuffers *before* allocating an MMIO address, while the hyperv_fb drivers removes conflicting framebuffers *after* allocating an MMIO address. With the "after" ordering, hyperv_fb may encounter a conflict and move the framebuffer to a different MMIO address. But the conflict is essentially bogus because it is removed a few lines of code later. Rather than fix the problem with the approach from 2020 in commit 3cb73bc3fa2a, instead slightly reorder the steps in hyperv_fb so conflicting framebuffers are removed before allocating an MMIO address. Then the default framebuffer MMIO address should always be available, and there's never any confusion about which framebuffer address the kdump kernel should use -- it's always the original address provided by the Hyper-V host. This approach is already used by the hyperv_drm driver, and is consistent with the usage guidelines at the head of the module with the function aperture_remove_conflicting_devices(). This approach also solves a related minor problem when kexec_load() is used to load the kdump kernel. With current code, unbinding and rebinding the hyperv_fb driver could result in the framebuffer moving back to the default framebuffer address, because on the rebind there are no conflicts. If such a move is done after the kdump kernel is loaded with the new framebuffer address, at kdump time it could again have the wrong address. This problem and fix are described in terms of the kdump kernel, but it can also occur with any kernel started via kexec. See extensive discussion of the problem and solution at [2]. [1] https://lore.kernel.org/linux-hyperv/20201014092429.1415040-1-kasong@redhat.com/ [2] https://lore.kernel.org/linux-hyperv/BLAPR10MB521793485093FDB448F7B2E5FDE92@BLAPR10MB5217.namprd10.prod.outlook.com/ Reported-by: Thomas Tai <thomas.tai@oracle.com> Fixes: c25a19afb81c ("fbdev/hyperv_fb: Do not clear global screen_info") Signed-off-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/20250218230130.3207-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250218230130.3207-1-mhklinux@outlook.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-22fbdev: hyperv_fb: iounmap() the correct memory when removing a deviceMichael Kelley
[ Upstream commit 7241c886a71797cc51efc6fadec7076fcf6435c2 ] When a Hyper-V framebuffer device is removed, or the driver is unbound from a device, any allocated and/or mapped memory must be released. In particular, MMIO address space that was mapped to the framebuffer must be unmapped. Current code unmaps the wrong address, resulting in an error like: [ 4093.980597] iounmap: bad address 00000000c936c05c followed by a stack dump. Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") changed the kind of address stored in info->screen_base, and the iounmap() call in hvfb_putmem() was not updated accordingly. Fix this by updating hvfb_putmem() to unmap the correct address. Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") Signed-off-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250209235252.2987-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250209235252.2987-1-mhklinux@outlook.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-21fbdev: omap: use threaded IRQ for LCD DMAAaro Koskinen
[ Upstream commit e4b6b665df815b4841e71b72f06446884e8aad40 ] When using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28 As a quick fix, switch to a threaded IRQ which provides a stable system. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08fbdev: omapfb: Fix an OF node leak in dss_of_port_get_parent_device()Joe Hattori
[ Upstream commit de124b61e179e690277116e6be512e4f422b5dd8 ] dss_of_port_get_parent_device() leaks an OF node reference when i >= 2 and struct device_node *np is present. Since of_get_next_parent() obtains a reference of the returned OF node, call of_node_put() before returning NULL. This was found by an experimental verifier that I am developing, and no runtime test was able to be performed due to that lack of actual devices. Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-05fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()Zhen Lei
[ Upstream commit f89d17ae2ac42931be2a0153fecbf8533280c927 ] When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead. Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver") Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-21fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPSArnd Bergmann
The fb_io_mmap() function is used in the file operations but not enabled in all configurations unless FB_IOMEM_FOPS gets selected: ld.lld-20: error: undefined symbol: fb_io_mmap referenced by wm8505fb.c drivers/video/fbdev/wm8505fb.o:(wm8505fb_ops) in archive vmlinux.a Fixes: 11754a504608 ("fbdev/wm8505fb: Initialize fb_ops to fbdev I/O-memory helpers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-15fbdev: da8xx: remove the driverBartosz Golaszewski
This driver is no longer used on any platform. It has been replaced by tilcdc on the two DaVinci boards we still support and can be removed. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-15fbdev: Constify struct sbus_mmap_mapChristophe JAILLET
'struct sbus_mmap_map' are not modified in these drivers. Constifying this structure moves some data to a read-only section, so increases overall security. Update sbusfb_mmap_helper() accordingly. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 2452 536 16 3004 bbc drivers/video/fbdev/bw2.o After: ===== text data bss dec hex filename 2500 483 16 2999 bb7 drivers/video/fbdev/bw2.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-15fbdev: nvidiafb: fix inconsistent indentation warningSurajSonawane2415
Fix the indentation to ensure consistent code style and improve readability, and to fix this warning: drivers/video/fbdev/nvidia/nv_hw.c:1512 NVLoadStateExt() warn: inconsistent indenting Signed-off-by: SurajSonawane2415 <surajsonawane0215@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-15fbdev: sstfb: Make CONFIG_FB_DEVICE optionalGonzalo Silvalde Blanco
The sstfb driver currently depends on CONFIG_FB_DEVICE to create sysfs entries and access info->dev. This patch wraps the relevant code blocks with #ifdef CONFIG_FB_DEVICE, allowing the driver to be built and used even if CONFIG_FB_DEVICE is not selected. The sysfs setting only controls the VGA pass-through state and is not required for the display to work correctly. (See: http://vogonswiki.com/index.php/VGA_passthrough_cable for more information.) Added some fixes from Thomas Zimmermann. Signed-off-by: Gonzalo Silvalde Blanco <gonzalo.silvalde@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-08fbdev: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/video/fbdev to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. While touching these files, make indention of the struct initializer consistent in several files. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-10-02move asm/unaligned.h to linux/unaligned.hAl Viro
asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
2024-09-28fbdev: sisfb: Fix strbuf array overflowAndrey Shumilin
The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Andrey Shumilin <shum.sdl@nppct.ru> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-26fbcon: break earlier in search_fb_in_map and search_for_mapped_conQianqiang Liu
Break the for loop immediately upon finding the target, making the process more efficient. Signed-off-by: Qianqiang Liu <qianqiang.liu@163.com> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-26fbdev: omapfb: Call of_node_put(ep) only once in ↵Markus Elfring
omapdss_of_find_source_for_first_ep() An of_node_put(ep) call was immediately used after a pointer check for a of_graph_get_remote_port() call in this function implementation. Thus call such a function only once instead directly before the check. This issue was transformed by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-26fbcon: Fix a NULL pointer dereference issue in fbcon_putcsQianqiang Liu
syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, &param); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, &param), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs. Reported-by: syzbot+3d613ae53c031502687a@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3d613ae53c031502687a Tested-by: syzbot+3d613ae53c031502687a@syzkaller.appspotmail.com Signed-off-by: Qianqiang Liu <qianqiang.liu@163.com> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-23Merge tag 'backlight-next-6.12' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight update from Lee Jones: - Added a check for the return value of spi_setup() in the l4f00242t03 driver to catch errors * tag 'backlight-next-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: backlight: l4f00242t03: Add check for spi_setup
2024-09-19Merge tag 'drm-next-2024-09-19' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm updates from Dave Airlie: "This adds a couple of patches outside the drm core, all should be acked appropriately, the string and pstore ones are the main ones that come to mind. Otherwise it's the usual drivers, xe is getting enabled by default on some new hardware, we've changed the device number handling to allow more devices, and we added some optional rust code to create QR codes in the panic handler, an idea first suggested I think 10 years ago :-) string: - add mem_is_zero() core: - support more device numbers - use XArray for minor ids - add backlight constants - Split dma fence array creation into alloc and arm fbdev: - remove usage of old fbdev hooks kms: - Add might_fault() to drm_modeset_lock priming - Add dynamic per-crtc vblank configuration support dma-buf: - docs cleanup buddy: - Add start address support for trim function printk: - pass description to kmsg_dump scheduler: - Remove full_recover from drm_sched_start ttm: - Make LRU walk restartable after dropping locks - Allow direct reclaim to allocate local memory panic: - add display QR code (in rust) displayport: - mst: GUID improvements bridge: - Silence error message on -EPROBE_DEFER - analogix: Clean aup - bridge-connector: Fix double free - lt6505: Disable interrupt when powered off - tc358767: Make default DP port preemphasis configurable - lt9611uxc: require DRM_BRIDGE_ATTACH_NO_CONNECTOR - anx7625: simplify OF array handling - dw-hdmi: simplify clock handling - lontium-lt8912b: fix mode validation - nwl-dsi: fix mode vsync/hsync polarity xe: - Enable LunarLake and Battlemage support - Introducing Xe2 ccs modifiers for integrated and discrete graphics - rename xe perf to xe observation - use wb caching on DGFX for system memory - add fence timeouts - Lunar Lake graphics/media/display workarounds - Battlemage workarounds - Battlemage GSC support - GSC and HuC fw updates for LL/BM - use dma_fence_chain_free - refactor hw engine lookup and mmio access - enable priority mem read for Xe2 - Add first GuC BMG fw - fix dma-resv lock - Fix DGFX display suspend/resume - Use xe_managed for kernel BOs - Use reserved copy engine for user binds on faulting devices - Allow mixing dma-fence jobs and long-running faulting jobs - fix media TLB invalidation - fix rpm in TTM swapout path - track resources and VF state by PF i915: - Type-C programming fix for MTL+ - FBC cleanup - Calc vblank delay more accurately - On DP MST, Enable LT fallback for UHBR<->non-UHBR rates - Fix DP LTTPR detection - limit relocations to INT_MAX - fix long hangs in buddy allocator on DG2/A380 amdgpu: - Per-queue reset support - SDMA devcoredump support - DCN 4.0.1 updates - GFX12/VCN4/JPEG4 updates - Convert vbios embedded EDID to drm_edid - GFX9.3/9.4 devcoredump support - process isolation framework for GFX 9.4.3/4 - take IOMMU mappings into account for P2P DMA amdkfd: - CRIU fixes - HMM fix - Enable process isolation support for GFX 9.4.3/4 - Allow users to target recommended SDMA engines - KFD support for targetting queues on recommended SDMA engines radeon: - remove .load and drm_dev_alloc - Fix vbios embedded EDID size handling - Convert vbios embedded EDID to drm_edid - Use GEM references instead of TTM - r100 cp init cleanup - Fix potential overflows in evergreen CS offset tracking msm: - DPU: - implement DP/PHY mapping on SC8180X - Enable writeback on SM8150, SC8180X, SM6125, SM6350 - DP: - Enable widebus on all relevant chipsets - MSM8998 HDMI support - GPU: - A642L speedbin support - A615/A306/A621 support - A7xx devcoredump support ast: - astdp: Support AST2600 with VGA - Clean up HPD - Fix timeout loop for DP link training - reorganize output code by type (VGA, DP, etc) - convert to struct drm_edid - fix BMC handling for all outputs exynos: - drop stale MAINTAINERS pattern - constify struct loongson: - use GEM refcount over TTM mgag200: - Improve BMC handling - Support VBLANK intterupts - transparently support BMC outputs nouveau: - Refactor and clean up internals - Use GEM refcount over TTM's gm12u320: - convert to struct drm_edid gma500: - update i2c terms lcdif: - pixel clock fix host1x: - fix syncpoint IRQ during resume - use iommu_paging_domain_alloc() imx: - ipuv3: convert to struct drm_edid omapdrm: - improve error handling - use common helper for_each_endpoint_of_node() panel: - add support for BOE TV101WUM-LL2 plus DT bindings - novatek-nt35950: improve error handling - nv3051d: improve error handling - panel-edp: - add support for BOE NE140WUM-N6G - revert support for SDC ATNA45AF01 - visionox-vtdr6130: - improve error handling - use devm_regulator_bulk_get_const() - boe-th101mb31ig002: - Support for starry-er88577 MIPI-DSI panel plus DT - Fix porch parameter - edp: Support AOU B116XTN02.3, AUO B116XAN06.1, AOU B116XAT04.1, BOE NV140WUM-N41, BOE NV133WUM-N63, BOE NV116WHM-A4D, CMN N116BCA-EA2, CMN N116BCP-EA2, CSW MNB601LS1-4 - himax-hx8394: Support Microchip AC40T08A MIPI Display panel plus DT - ilitek-ili9806e: Support Densitron DMT028VGHMCMI-1D TFT plus DT - jd9365da: - Support Melfas lmfbx101117480 MIPI-DSI panel plus DT - Refactor for code sharing - panel-edp: fix name for HKC MB116AN01 - jd9365da: fix "exit sleep" commands - jdi-fhd-r63452: simplify error handling with DSI multi-style helpers - mantix-mlaf057we51: simplify error handling with DSI multi-style helpers - simple: - support Innolux G070ACE-LH3 plus DT bindings - support On Tat Industrial Company KD50G21-40NT-A1 plus DT bindings - st7701: - decouple DSI and DRM code - add SPI support - support Anbernic RG28XX plus DT bindings mediatek: - support alpha blending - remove cl in struct cmdq_pkt - ovl adaptor fix - add power domain binding for mediatek DPI controller renesas: - rz-du: add support for RZ/G2UL plus DT bindings rockchip: - Improve DP sink-capability reporting - dw_hdmi: Support 4k@60Hz - vop: - Support RGB display on Rockchip RK3066 - Support 4096px width sti: - convert to struct drm_edid stm: - Avoid UAF wih managed plane and CRTC helpers - Fix module owner - Fix error handling in probe - Depend on COMMON_CLK - ltdc: - Fix transparency after disabling plane - Remove unused interrupt tegra: - gr3d: improve PM domain handling - convert to struct drm_edid - Call drm_atomic_helper_shutdown() vc4: - fix PM during detect - replace DRM_ERROR() with drm_error() - v3d: simplify clock retrieval v3d: - Clean up perfmon virtio: - add DRM capset" * tag 'drm-next-2024-09-19' of https://gitlab.freedesktop.org/drm/kernel: (1326 commits) drm/xe: Fix missing conversion to xe_display_pm_runtime_resume drm/xe/xe2hpg: Add Wa_15016589081 drm/xe: Don't keep stale pointer to bo->ggtt_node drm/xe: fix missing 'xe_vm_put' drm/xe: fix build warning with CONFIG_PM=n drm/xe: Suppress missing outer rpm protection warning drm/xe: prevent potential UAF in pf_provision_vf_ggtt() drm/amd/display: Add all planes on CRTC to state for overlay cursor drm/i915/bios: fix printk format width drm/i915/display: Fix BMG CCS modifiers drm/amdgpu: get rid of bogus includes of fdtable.h drm/amdkfd: CRIU fixes drm/amdgpu: fix a race in kfd_mem_export_dmabuf() drm: new helper: drm_gem_prime_handle_to_dmabuf() drm/amdgpu/atomfirmware: Silence UBSAN warning drm/amdgpu: Fix kdoc entry in 'amdgpu_vm_cpu_prepare' drm/amd/amdgpu: apply command submission parser for JPEG v1 drm/amd/amdgpu: apply command submission parser for JPEG v2+ drm/amd/pm: fix the pp_dpm_pcie issue on smu v14.0.2/3 drm/amd/pm: update the features set on smu v14.0.2/3 ...
2024-09-18Merge tag 'fbdev-for-6.12-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev Pull fbdev updates from Helge Deller: - video: Reduce code when CONFIG_HAS_IOPORT=n - xenfb: Fix crash by assigning fb_info->device - pxafb: Fix possible use after free in pxafb_task() - efifb: Introduce and use new devm_register_framebuffer() function - mmpfb: Utilize devm_clk_get_enabled() helpers - various typo fixes and code cleanups * tag 'fbdev-for-6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev: fbdev: omapfb: Fix typo in comment fbdev: pxafb: Fix possible use after free in pxafb_task() fbdev: xen-fbfront: Assign fb_info->device fbdev: hyperv_fb: Convert comma to semicolon fbdev: imsttfb: convert comma to semicolon fbdev: pxa3xx-gcu: Convert comma to semicolon fbdev: efifb: Use driver-private screen_info for sysfs fbdev: efifb: Use devm_register_framebuffer() fbdev: efifb: Register sysfs groups through driver core fbdev: Introduce devm_register_framebuffer() fbdev: omapfb: Use sysfs_emit_at() to simplify code fbdev: omapfb: panel-sony-acx565akm: Simplify show_cabc_available_modes() fbdev: mmp: Use devm_clk_get_enabled() helpers fbdev: hpfb: Fix an error handling path in hpfb_dio_probe() video: Handle HAS_IOPORT dependencies
2024-09-11fbdev: omapfb: Fix typo in commentAndrew Kreimer
Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-11fbdev: pxafb: Fix possible use after free in pxafb_task()Kaixin Wang
In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime. Signed-off-by: Kaixin Wang <kxwang23@m.fudan.edu.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-11Merge v6.11-rc7 into drm-nextSimona Vetter
Thomas needs 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary") in drm-misc, so start the backmerge cascade. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2024-09-11fbdev: xen-fbfront: Assign fb_info->deviceJason Andryuk
Probing xen-fbfront faults in video_is_primary_device(). The passed-in struct device is NULL since xen-fbfront doesn't assign it and the memory is kzalloc()-ed. Assign fb_info->device to avoid this. This was exposed by the conversion of fb_is_primary_device() to video_is_primary_device() which dropped a NULL check for struct device. Fixes: f178e96de7f0 ("arch: Remove struct fb_info from video helpers") Reported-by: Arthur Borsboom <arthurborsboom@gmail.com> Closes: https://lore.kernel.org/xen-devel/CALUcmUncX=LkXWeiSiTKsDY-cOe8QksWhFvcCneOKfrKd0ZajA@mail.gmail.com/ Tested-by: Arthur Borsboom <arthurborsboom@gmail.com> CC: stable@vger.kernel.org Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-02fbdev: hyperv_fb: Convert comma to semicolonChen Ni
Replace a comma between expression statements by a semicolon. Fixes: d786e00d19f9 ("drivers: hv, hyperv_fb: Untangle and refactor Hyper-V panic notifiers") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-02fbdev: imsttfb: convert comma to semicolonChen Ni
Replace a comma between expression statements by a semicolon. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2024-09-02fbdev: pxa3xx-gcu: Convert comma to semicolonChen Ni
Replace a comma between expression statements by a semicolon. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-30fbdev: efifb: Use driver-private screen_info for sysfsThomas Weißschuh
Since commit b9cfd1d271ab ("fbdev/efifb: Use screen_info pointer from device") efifb uses a local copy of screen_info and applies its modifications there. Adapt the sysfs attributes to also work with the custom copy instead of the unmodified platform data. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-30fbdev: efifb: Use devm_register_framebuffer()Thomas Weißschuh
This simplifies the error handling. Also the drvdata slot is now unused and can be used for other usecases. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-30fbdev: efifb: Register sysfs groups through driver coreThomas Weißschuh
The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-30fbdev: Introduce devm_register_framebuffer()Thomas Weißschuh
Introduce a device-managed variant of register_framebuffer() which automatically unregisters the framebuffer on device destruction. This can simplify the error handling and resource management in drivers. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-30fbdev: omapfb: Use sysfs_emit_at() to simplify codeChristophe JAILLET
This file already uses sysfs_emit(). So be consistent and also use sysfs_emit_at(). Moreover, size is always < PAGE_SIZE because scnprintf() (and now sysfs_emit_at()) returns the number of characters written not including the trailing '\0'. So some tests can be removed. This slightly simplifies the code and makes it more readable. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Helge Deller <deller@gmx.de>