summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-10-13PCI: qcom: Block accesses to downstream devices on link downQiang Yu
After a PCIe link goes down, software may still access the BAR (MMIO) space or configuration space of devices behind that link before recovery has run. As the link is down, these accesses never complete, resulting in a storm of Completion Timeout AERs. Use the controller's Outbound blocker to drop these accesses to the PCIe address space as soon as the link-down interrupt fires, so that Completion Timeout AERs are reduced. The blocked range covers the entire address space (base 0x0, all-ones limit), since the Root Port's own DBI/iATU register space remains accessible regardless. The range is programmed once in the host init path, since the range registers are wiped by BCR reset. This leaves only the OUTBOUND_BLOCKER_EN bit to be flipped from the link-down IRQ handler, so the blocker can be armed with a single fast register write for immediate effect. The subsequent Root Port reset re-initialises the controller, which clears the enable bit and re-programs the range for the fresh link. Some IP revisions implement the Outbound blocker registers but do not wire up the "global" interrupt used to deliver the link-down event that arms the blocker, so there is no way to enable the blocker on those platforms. Restrict blocker initialization to the post_init hooks of the IP revisions that do have a global IRQ wired up (qcom_pcie_post_init_2_3_3(), qcom_pcie_post_init_2_7_0() and qcom_pcie_post_init_2_9_0()), instead of unconditionally programming it from the common host_init path. The link-down IRQ thread's blocker-enable write to PARF_SYS_CTRL can race with a Root Port reset triggered independently through AER, which reprograms PARF_SYS_CTRL as part of reinitializing the controller. Serialize these with a per-controller mutex. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: renamed hw_lock to reset_lock, ECAM blocker to Outboound blocker, used guard(mutex)] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD + ASUS PA27AC Link: https://patch.msgid.link/20260819-ecam_blocker-v2-1-e7a8fdc1c5cb@oss.qualcomm.com
2026-10-13bnge: skip dev_addr when building the VNIC unicast listVikas Gupta
The default VNIC programs the device's MAC as L2 filter 0 in bnge_init_chip() via bnge_hwrm_set_vnic_filter(bn, 0, 0, dev_addr). bnge_cfg_rx_mode() then walks dev->uc and programs each unicast address as a further L2 filter, without excluding dev_addr. Skip dev_addr when building uc_list, since it is already installed as filter 0. As dev_addr now takes neither a uc_list slot nor an l2_filters[] slot, count only the non-dev_addr entries for the uc_list overflow check too, otherwise an input such as {dev_addr, A, B, C} would needlessly fall back to promiscuous mode even though A, B and C fit in exact-match filters. bnge_uc_list_updated() applies the same skip and count so the change detection stays consistent and does not loop. This issue was caught by Sashiko (nipa). Tested on Thor Ultra device. Fixes: 9afad4a17174 ("bng_en: Configure default VNIC") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com> Link: https://patch.msgid.link/20261006141928.1432927-1-vikas.gupta@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-10-13selftests/liveupdate: Prefer KVM and HVF over TCG in vmtest.shDavid Matlack
Pass the -accel options to QEMU in the order KVM, HVF, TCG, so that vmtest.sh prefers to use KVM and HVF over TCG when they are available. QEMU uses the first accelerator in the list that initializes, and TCG always initializes, so the tests currently always run under TCG, even though the commit that added vmtest.sh describes "automatic accelerator detection (KVM, HVF, or TCG)". Fixes: 89dd1421c554 ("selftests/liveupdate: add end to end test infrastructure and scripts") Signed-off-by: David Matlack <dmatlack@google.com> Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Link: https://patch.msgid.link/20261008132813.1966023-1-dmatlack@google.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-10-13netlink: reset skb headers before unicast and multicast filteringKyle Zeng
Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb's network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket's filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver's filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code. Fixes: b1153f29ee07 ("netlink: make socket filters work on netlink") Assisted-by: LLM Signed-off-by: Kyle Zeng <kylebot@openai.com> Link: https://patch.msgid.link/20261006224232.50724-1-kylebot@openai.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-10-13ALSA: pcm: Protect delay DMA sync against concurrent HW_FREECen Zhang
A PCM DMA buffer must remain allocated until explicit DMA synchronization finishes. snd_pcm_delay() calls snd_pcm_dma_buffer_sync() after dropping the stream lock, without participating in the buffer-access exclusion used by HW_FREE. With a managed NONCONTIG buffer requiring explicit sync, HW_PARAMS can allocate a separate runtime descriptor when the requested ring exceeds the preallocation. In PREPARED state with mmap_count zero, concurrent HWSYNC and HW_FREE calls on the same open PCM file can interleave: 1. HWSYNC checks the state in snd_pcm_delay() under the stream lock and releases that lock. 2. The sync helper fetches runtime->dma_buffer_p and enters snd_dma_noncontig_sync() with that descriptor. 3. HW_FREE takes the negative buffer-access count, checks PREPARED under the stream lock, releases the lock, and frees the DMA allocation and dynamic descriptor through snd_pcm_lib_free_pages(). 4. The sync callback resumes and reads the freed descriptor. The stream lock does not cover the allocation's release, and the sync operation has no positive buffer-access count to prevent it. The stale read causes a use-after-free in snd_dma_noncontig_sync(). DELAY uses the same snd_pcm_delay() path. Take a positive buffer-access count before checking the state and keep it until the DMA sync finishes, as the transfer and mmap paths already do. HW_FREE then returns -EBUSY while this access is active. If a buffer writer has already entered, snd_pcm_delay() returns -EBUSY before using the buffer. Keep the sync outside the stream lock and balance the count on the state-error path as well. KASAN report as below: BUG: KASAN: slab-use-after-free in snd_dma_noncontig_sync+0x295/0x310 [snd_pcm] Read of size 4 at addr ffff888108f58584 by task pcm-uaf-fixture/487 CPU: 1 UID: 0 PID: 487 Comm: pcm-uaf-fixture Not tainted 7.2.0-rc6-pmb-alsa-functional-v2+ #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x93/0xd0 print_report+0xce/0x630 ? snd_dma_noncontig_sync+0x295/0x310 [snd_pcm] ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x20d/0x410 ? snd_dma_noncontig_sync+0x295/0x310 [snd_pcm] kasan_report+0xe0/0x110 ? snd_dma_noncontig_sync+0x295/0x310 [snd_pcm] ? __pfx_snd_dma_noncontig_sync+0x10/0x10 [snd_pcm] snd_dma_noncontig_sync+0x295/0x310 [snd_pcm] ? __pfx_snd_dma_noncontig_sync+0x10/0x10 [snd_pcm] snd_dma_buffer_sync+0xc9/0x110 [snd_pcm] snd_pcm_delay+0x3bd/0x550 [snd_pcm] snd_pcm_common_ioctl+0x1e7/0x3aa0 [snd_pcm] ? srso_alias_return_thunk+0x5/0xfbef5 ? do_vfs_ioctl+0x1f5/0x1280 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x34f/0x500 ? __pfx_snd_pcm_common_ioctl+0x10/0x10 [snd_pcm] ? srso_alias_return_thunk+0x5/0xfbef5 snd_pcm_ioctl+0x76/0xb0 [snd_pcm] ? __pfx_snd_pcm_ioctl+0x10/0x10 [snd_pcm] __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1cae7ab91b Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007ffe12d544f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f1cae7ab91b RDX: 0000000000000000 RSI: 0000000000004122 RDI: 0000000000000003 RBP: 00000000000001ee R08: 0000000000000073 R09: 00000000ffffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 R13: 0000000000000001 R14: 00005584f32b1398 R15: 00005584f32b2ce8 </TASK> Allocated by task 487: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_cache_noprof+0x251/0x610 snd_pcm_lib_malloc_pages+0x27c/0x9f0 [snd_pcm] snd_pcm_hw_params+0x171c/0x1d10 [snd_pcm] snd_pcm_common_ioctl+0x1f62/0x3aa0 [snd_pcm] snd_pcm_ioctl+0x76/0xb0 [snd_pcm] __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 499: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x307/0x580 snd_pcm_lib_free_pages+0x1c9/0x420 [snd_pcm] snd_pcm_common_ioctl+0x2bd3/0x3aa0 [snd_pcm] snd_pcm_ioctl+0x76/0xb0 [snd_pcm] __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888108f58580 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 4 bytes inside of freed 64-byte region [ffff888108f58580, ffff888108f585c0) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x108f58 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000428c0 dead000000000100 dead000000000122 raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888108f58480: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff888108f58500: 00 00 00 00 00 06 fc fc fc fc fc fc fc fc fc fc >ffff888108f58580: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ffff888108f58600: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff888108f58680: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint ------------[ cut here ]------------ kernel BUG at kernel/dma/mapping.c:417! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 1 UID: 0 PID: 487 Comm: pcm-uaf-fixture Tainted: G B 7.2.0-rc6-pmb-alsa-functional-v2+ #1 PREEMPT(lazy) Tainted: [B]=BAD_PAGE Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__dma_sync_sg_for_cpu+0x230/0x360 Code: df 48 c1 e8 03 80 3c 10 00 0f 85 fa 00 00 00 4c 8b 35 d4 6b 7a 09 e8 7f e2 17 00 83 fd 02 0f 86 39 fe ff ff e8 71 e2 17 00 90 <0f> 0b e8 69 e2 17 00 be 08 00 00 00 4c 89 ff e8 bc 5f 77 00 4c 89 RSP: 0018:ffff888111f3fc50 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffffc0250d10 RCX: ffffffff816d395f RDX: ffff88810836ba00 RSI: ffff888108f58580 RDI: ffffffffc02510d8 RBP: 00000000ffff8881 R08: 0000000000000000 R09: fffffbfff804a239 R10: ffffffffc02511cf R11: 6e696c6261736944 R12: ffff888108f58580 R13: 0000000002ce00e5 R14: ffffffffc0258720 R15: 0000000000000000 FS: 00007f1cae69c780(0000) GS:ffff8881fd861000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d1affa2480 CR3: 0000000108fc0003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> snd_dma_noncontig_sync+0x15a/0x310 [snd_pcm] ? __pfx_snd_dma_noncontig_sync+0x10/0x10 [snd_pcm] snd_dma_buffer_sync+0xc9/0x110 [snd_pcm] snd_pcm_delay+0x3bd/0x550 [snd_pcm] snd_pcm_common_ioctl+0x1e7/0x3aa0 [snd_pcm] ? srso_alias_return_thunk+0x5/0xfbef5 ? do_vfs_ioctl+0x1f5/0x1280 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x34f/0x500 ? __pfx_snd_pcm_common_ioctl+0x10/0x10 [snd_pcm] ? srso_alias_return_thunk+0x5/0xfbef5 snd_pcm_ioctl+0x76/0xb0 [snd_pcm] ? __pfx_snd_pcm_ioctl+0x10/0x10 [snd_pcm] __x64_sys_ioctl+0x163/0x1d0 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1cae7ab91b Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007ffe12d544f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f1cae7ab91b RDX: 0000000000000000 RSI: 0000000000004122 RDI: 0000000000000003 RBP: 00000000000001ee R08: 0000000000000073 R09: 00000000ffffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 R13: 0000000000000001 R14: 00005584f32b1398 R15: 00005584f32b2ce8 </TASK> Modules linked in: snd_pcmtest snd_pcm ---[ end trace 0000000000000000 ]--- RIP: 0010:__dma_sync_sg_for_cpu+0x230/0x360 Code: df 48 c1 e8 03 80 3c 10 00 0f 85 fa 00 00 00 4c 8b 35 d4 6b 7a 09 e8 7f e2 17 00 83 fd 02 0f 86 39 fe ff ff e8 71 e2 17 00 90 <0f> 0b e8 69 e2 17 00 be 08 00 00 00 4c 89 ff e8 bc 5f 77 00 4c 89 RSP: 0018:ffff888111f3fc50 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffffc0250d10 RCX: ffffffff816d395f RDX: ffff88810836ba00 RSI: ffff888108f58580 RDI: ffffffffc02510d8 RBP: 00000000ffff8881 R08: 0000000000000000 R09: fffffbfff804a239 R10: ffffffffc02511cf R11: 6e696c6261736944 R12: ffff888108f58580 R13: 0000000002ce00e5 R14: ffffffffc0258720 R15: 0000000000000000 FS: 00007f1cae69c780(0000) GS:ffff8881fd861000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d1affa2480 CR3: 0000000108fc0003 CR4: 0000000000770ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Rebooting in 1 seconds.. Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation") Assisted-by: LLM Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/pm-pmb-d74585d187e0b1810c08-v2-25432d0951f67fdaa1a9@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-13Merge patch series "memblock: Remove unused exact nid allocation API"Mike Rapoport (Microsoft)
Kaitao Cheng <kaitao.cheng@linux.dev> says: memblock: Remove unused exact nid allocation API Commit ffe55393137c ("mm/sparse: remove sparse buffer pre-allocation mechanism") removed the only memmap_alloc() caller that requested an allocation from an exact NUMA node. All remaining callers allow fallback to other nodes, leaving the exact_nid argument unused. Remove the argument from memmap_alloc(). This leaves memblock_alloc_exact_nid_raw() without any in-kernel callers, so move the applicable exact-node allocation tests to memblock_alloc_range_nid() and remove the unused API. Also remove the exact_nid argument from the internal allocation helper, since all of its remaining callers allow fallback. Exact-node allocation remains a required behavior of memblock_alloc_range_nid(). CMA uses it when reserving per-node CMA areas; allowing fallback could leave the area's recorded nid inconsistent with the physical location of its memory. KHO also uses it for per-node scratch areas that must remain on the requested node. Therefore, retain coverage of this behavior by making the applicable NUMA tests call memblock_alloc_range_nid() directly with exact_nid set. The tests that exercise memblock_alloc_internal() retrying below min_addr cannot be retained unchanged. Unlike memblock_alloc_internal(), memblock_alloc_range_nid() treats its start address as a hard boundary and does not retry from address zero. Remove those tests along with the now unused TEST_F_EXACT dispatch from the shared allocation tests. * patches from https://patch.msgid.link/20260919135327.74089-1-kaitao.cheng@linux.dev mm: Remove unused exact_nid parameter from memmap_alloc() memblock tests: Move exact nid tests to memblock_alloc_range_nid() memblock: Remove unused memblock_alloc_exact_nid_raw() Link: https://patch.msgid.link/20260919135327.74089-1-kaitao.cheng@linux.dev Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-10-13memblock: Remove unused memblock_alloc_exact_nid_raw()Kaitao Cheng
memmap_alloc() was the only in-kernel caller of memblock_alloc_exact_nid_raw(). After removing its unused exact_nid argument, the function no longer has any callers. Remove memblock_alloc_exact_nid_raw() and its declaration. The remaining callers of memblock_alloc_internal() always allow allocation to fall back to other NUMA nodes, so remove its exact_nid argument and pass false directly to memblock_alloc_range_nid(). Suggested-by: Lorenzo Stoakes <ljs@kernel.org> Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn> Link: https://patch.msgid.link/20260919135327.74089-4-kaitao.cheng@linux.dev Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-10-13memblock tests: Move exact nid tests to memblock_alloc_range_nid()Kaitao Cheng
After memmap_alloc() stopped requesting allocations from an exact NUMA node, memblock_alloc_exact_nid_raw() no longer has any in-kernel users and is being removed. Preserve coverage of exact-node allocation by converting the applicable NUMA tests to call memblock_alloc_range_nid() with exact_nid set. Remove the tests that depend on memblock_alloc_internal() retrying below min_addr, as memblock_alloc_range_nid() treats its address range as a hard constraint. Remove the now-unused TEST_F_EXACT support from the shared allocation tests. Suggested-by: Lorenzo Stoakes <ljs@kernel.org> Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn> Link: https://patch.msgid.link/20260919135327.74089-3-kaitao.cheng@linux.dev Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-10-13mm: Remove unused exact_nid parameter from memmap_alloc()Kaitao Cheng
Commit ffe55393137c ("mm/sparse: remove sparse buffer pre-allocation mechanism") removed sparse_buffer_init(), which was the only caller of memmap_alloc() that passed true for exact_nid. All remaining callers pass false, leaving the exact-node allocation branch unreachable. Remove the exact_nid parameter and unconditionally use memblock_alloc_try_nid_raw(). This has no functional impact. Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn> Link: https://patch.msgid.link/20260919135327.74089-2-kaitao.cheng@linux.dev Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2026-10-13ALSA: rawmidi: Drain input work before freeing the runtimeCen Zhang
The input runtime embeds event_work, so the work must be drained before close_substream() frees the runtime. The cancellation in snd_rawmidi_input_trigger() runs before close clears substream->opened, leaving a window for snd_rawmidi_receive() to enqueue more work. With a sequencer subscription to a USB MIDI input port, an in-flight completion can overlap the last subscription's midisynth_unsubscribe(): 1. snd_usbmidi_input_data() observes input_triggered and is delayed before calling snd_rawmidi_receive(). 2. Unsubscribe enters close_substream(), clears input_triggered through the provider trigger callback and returns from cancel_work_sync(). The substream is still opened. 3. The completion resumes. snd_rawmidi_receive() takes substream->lock, sees opened set and queues runtime->event_work before dropping the lock. 4. Close clears opened under that lock, closes the provider and frees the runtime. Stopping USB URBs does not drain the raw-MIDI work. 5. The queued work runs and snd_rawmidi_input_event_work() reads event or substream from the freed runtime, causing a use-after-free. Cancel input event_work again after clearing opened, before closing the provider or releasing the runtime's private data. Receive holds substream->lock through its opened check and work enqueue, so once close has cleared opened under that lock, no further receive can queue work. The final cancellation therefore drains any late work before the runtime is freed. Keep it outside the spinlock so a running callback can finish. Fixes: b3c705aa9e91 ("ALSA: rawmidi - Use workq for event handling") Assisted-by: LLM Signed-off-by: Cen Zhang <zzzccc427@gmail.com> Link: https://patch.msgid.link/pm-pmb-98489078ab56528d8e4a-v2-9408ce8c8f3c70b5c10d@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-13ALSA: hda/realtek: Add GPIO2 low quirk for ASUS E5402WHAZhang Heng
The internal speaker amplifier on the ASUS ExpertCenter AIO E5402WHA (ALC256, SSID 1043:3500) is enabled via GPIO2 and is active-low. Driving GPIO2 high, as ALC256_FIXUP_ASUS_AIO_GPIO2 does on the ZN270IE, keeps the speakers muted. Add a dedicated fixup that drives GPIO2 low so the internal speakers work. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221938 Tested-by: Johan den Hollander <johan.den.hollander@finalist.nl> Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20261013071255.270131-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-10-13MAINTAINERS: name the deller/linux-fbdev for-next branchMatthias Goergens
The T: entry for FRAMEBUFFER LAYER names deller/linux-fbdev without a branch. The repository's HEAD points to branch master, which mainline already contains. linux-next merges the for-next branch of this repository (Next/Trees). Name that branch in the entry. Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com> Acked-by: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: atafb: avoid cast when assigning buffer address pointerHelge Deller
The sparse tool complains that the "cast removes the address space '__iomem' of expression". Avoid the cast by using the screen_buffer pointer instead of the screen_base pointer from the union. Fixes: d463633d63e6 ("fbdev: atafb: Add support for SuperVidel's SuperBlitter") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202609261313.kgFtkz2t-lkp@intel.com/ Cc: Miro Kropáček <miro.kropacek@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: atafb: fix sparse warningsHelge Deller
Fix two sparse warnings: - atafb.c:1092: sparse: Using plain integer as NULL pointer Use NULL instead of 0 when assigning a pointer. - atafb.c:2824: sparse: switch with no cases FBCMD_GET_CURRENTPAR and and FBCMD_SET_CURRENTPAR seem to be historic defines, which are not any longer in the kernel, and as such the code isn't built any longer and may be dropped. Fixes: d463633d63e6 ("fbdev: atafb: Add support for SuperVidel's SuperBlitter") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202609261313.kgFtkz2t-lkp@intel.com/ Cc: Miro Kropacek <miro.kropacek@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>
2026-10-13fbdev: atyfb_base: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: aty128fb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: mach64: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: radeonfb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: omap2fb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: ocfb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: skeletonfb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: pm2fb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: maxinefb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: kyro: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: grvga: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: efifb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: au1100fb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: mmp: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: tridentfb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: tgafb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: sstfb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: viafb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: sticore: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: s1d13xxxfb: fix typos in commentsHemanth Selam
Assisted-by: Cursor:claude-opus-5 Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: Drop unused FB_IOMEM_HELPERS_DEFERRED Kconfig optionHelge Deller
Signed-off-by: Helge Deller <deller@gmx.de> Noticed-by: Breno Rodrigues Alves <breno3011alves@gmail.com>
2026-10-13fbdev: sstfb: use managed PCI device enableMyeonghun Pak
sstfb_probe() enables the PCI device with pci_enable_device(), but failure paths after that point return without disabling it. The successful probe path has the same imbalance because sstfb_remove() releases the framebuffer, mappings and memory regions, but never calls pci_disable_device(). Use pcim_enable_device() so the PCI core disables the device automatically after probe failure or driver removal. The driver still releases its framebuffer, mappings and memory regions explicitly. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: acornfb: remove unused code for 26-bit hardwareEthan Nelson-Moore
The acornfb driver contains code to support machines with a MEMC chip and without IOMD and VIDC20 chips. All 32-bit Acorn hardware has IOMD and VIDC20 chips and does not have a MEMC chip. Linux formerly supported 26-bit Acorn computers, but that support was removed in commit 99eb8a550dbc ("Remove the arm26 port") because it had bitrotted to the extent that it did not even compile. Remove this unused code. Also take the opportunity to remove incorrect file paths in the file headers, which are bad style regardless. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: nvidia: Release write-combining handle on probe failureMyeonghun Pak
Failures in nvidia_set_fbinfo() or register_framebuffer() leave the handle from arch_phys_wc_add() allocated. Release it in the shared error path, as nvidiafb_remove() already does on normal removal. The missing cleanup was already present in the initial Git import, when the driver used mtrr_add() directly. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: kyro: Release WC setup on registration failureMyeonghun Pak
If register_framebuffer() fails, kyrofb_probe() frees the framebuffer without releasing its write-combining range. Release the range before freeing the framebuffer. Earlier failures still skip this cleanup. The missing cleanup already exists in the initial Git import, before the conversion from mtrr_add() to arch_phys_wc_add(). This issue was identified during our ongoing static-analysis research while reviewing kernel code. Cc: stable@vger.kernel.org Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: gxt4500: Release WC setup on probe failureMyeonghun Pak
gxt4500_probe() adds a write-combining range before allocating the cmap and registering the framebuffer. If a later step fails, the range is not released. Add the missing cleanup before unmapping the framebuffer, matching the successful remove path. This issue was identified during our ongoing static-analysis research while reviewing kernel code. Fixes: 38fc4d45fae5 ("gxt4500: Use arch_phys_wc_* for framebuffer") Assisted-by: LLM Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: atmel_lcdfb: Prevent FIFO work after removalYibo Tan
The LCD controller IRQ schedules sinfo->task to recover from a FIFO underflow. Probe currently requests the IRQ before initializing the work, so an early interrupt can schedule an uninitialized work item. The probe error path and remove path cancel the work before freeing the IRQ. A FIFO-underflow interrupt can schedule the work again after that cancellation. framebuffer_release() may then free sinfo while the work is still pending. KASAN reported a use-after-free in atmel_lcdfb_task() when an underflow interrupt occurred during removal. With the IRQ freed before the work was cancelled, the same test completed without a kernel diagnostic. Initialize the work before requesting the IRQ. In both cleanup paths, free the IRQ before cancelling the work so that it cannot be scheduled again after cancellation. Fixes: d22579b83735 ("atmel_lcdfb: FIFO underflow management") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Yibo Tan <lhfff@tju.edu.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: sh_mobile_lcdc: check for fb_deferred_io_init() errorLorenzo Stoakes (ARM)
fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently sh_mobile_lcdc_start() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Also clear info->fbdefio in that case, so that sh_mobile_lcdc_stop() does not attempt to clean up deferred I/O state that was never initialised. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: smscufx: check for fb_deferred_io_init() errorLorenzo Stoakes (ARM)
fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently ufx_ops_open() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. fb_open() will then dereference a NULL pointer (calling fb_deferred_io_open()) as soon as ufx_ops_open() returns. Additionally, if the allocation of info->fbdefio itself fails, ufx_ops_open() sets info->fbdefio to NULL and invokes fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio). Fix this by only invoking fb_deferred_io_init() if the allocation succeeded, and checking for the error. The driver already supports operating without deferred I/O, so in either case fall back to that by setting info->fbdefio to NULL. The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct"). However, the BUG_ON() issue originates from the earlier commit 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters"), so target that for the fix. Fixes: 3c8a63e22a08 ("Add support for SMSC UFX6000/7000 USB display adapters") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: udlfb: check for fb_deferred_io_init() errorLorenzo Stoakes (ARM)
fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently dlfb_ops_open() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. fb_open() will then dereference a NULL pointer (calling fb_deferred_io_open()) as soon as dlfb_ops_open() returns. Additionally, if the allocation of info->fbdefio itself fails, dlfb_ops_open() sets info->fbdefio to NULL and invokes fb_deferred_io_init() regardless, hitting BUG_ON(!fbdefio). Fix this by only invoking fb_deferred_io_init() if the allocation succeeded, and checking for the error. The driver already supports operating without deferred I/O, so in either case fall back to that by setting info->fbdefio to NULL. The ignored return value was introduced in commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct"). However, the BUG_ON() issue originates from the earlier commit 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers"), so target that for the fix. Fixes: 5bea1fbf9423 ("staging: udlfb: fix incorrect fb_defio implementation for multiple framebuffers") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13HID: picoLCD: check for fb_deferred_io_init() errorLorenzo Stoakes (ARM)
fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently picolcd_init_framebuffer() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Also correct cleanup ordering - defio is initialised after the sysfs file, so cleanup defio first. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: xen-fbfront: check for fb_deferred_io_init() errorLorenzo Stoakes (ARM)
fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently xenfb_probe() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: ssd1307fb: check for fb_deferred_io_init() errorLorenzo Stoakes (ARM)
fb_deferred_io_init() allocates deferred I/O state, populating info->fbdefio_state, or leaving it NULL if an error occurs. Currently ssd1307fb_probe() ignores its return value. Therefore if an error arises in fb_deferred_io_init() (for instance, due to an allocation failure) info->fbdefio_state is left NULL. When the file is subsequently opened, fb_open() will dereference a NULL pointer (calling fb_deferred_io_open()). Fix this by checking for the error. Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: core: Initialize modelist in framebuffer_alloc()Andrey Misiurov
framebuffer_alloc() returns zeroed memory, so info->modelist starts out with NULL next and prev pointers. The list head is initialized only later, by fb_videomode_to_modelist() or by do_register_framebuffer(). The "fix potential memory leak" commits listed below added fb_destroy_modelist(&info->modelist) to the probe error paths of s3fb, tdfxfb, tridentfb, i740fb and carminefb. These paths can run before the list head is initialized: - s3fb, tdfxfb, tridentfb and i740fb call fb_videomode_to_modelist() only after a successful EDID read, and tridentfb can also hit the error path on an ioremap() or kmalloc() failure before that; - carminefb jumps to the error path when fb_find_mode() fails, before its fb_videomode_to_modelist() call. fb_destroy_modelist() then dereferences the NULL head. Reproduced on Debian 12 (6.1.180) by binding s3fb to a VGA device without EDID and forcing fb_alloc_cmap() to fail: s3fb 0000:00:03.0: cannot allocate colormap BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:fb_destroy_modelist+0x10/0x80 Call Trace: s3_pci_probe.cold+0x12b/0x2bf [s3fb] local_pci_probe+0x41/0x80 pci_device_probe+0xc3/0x240 really_probe+0xde/0x380 __driver_probe_device+0x84/0x150 driver_probe_device+0x1f/0x90 __driver_attach+0xce/0x1c0 bus_for_each_dev+0x87/0xd0 bus_add_driver+0x1ae/0x200 driver_register+0x89/0xe0 do_one_initcall+0x59/0x220 do_init_module+0x4a/0x1f0 Initialize the list head in framebuffer_alloc(), so info->modelist is always a valid, possibly empty, list and fb_destroy_modelist() is safe on every error path. Keep the lazy initialization in do_register_framebuffer(), as drivers that embed struct fb_info rather than calling framebuffer_alloc() still depend on it. Fixes: 3b0ed04bc852 ("fbdev: s3fb: fix potential memory leak in s3_pci_probe()") Fixes: bb019d755366 ("fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()") Fixes: 7a35ec619d9a ("fbdev: tridentfb: fix potential memory leak in trident_pci_probe()") Fixes: 5936063409af ("fbdev: i740fb: fix potential memory leak in i740fb_probe()") Fixes: 6fcca16a2b19 ("fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()") Cc: stable@vger.kernel.org Signed-off-by: Andrey Misiurov <andrey.misyrov@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: udlfb: don't rebuild the mode list while the framebuffer is in useXiang Mei
dlfb_setup_modes() frees info->modelist with fb_destroy_modelist() and rebuilds it, but fbcon holds raw pointers into that list in fb_display[i].mode and nothing un-publishes them the way do_unregister_framebuffer() and store_modes() do with fbcon_delete_modelist(). The function does refuse to install a new mode while the framebuffer has users (dlfb->fb_count != 0), but only after the list is already destroyed. Reached from the 0666 "edid" sysfs attribute, an unprivileged write to /sys/class/graphics/fb0/edid therefore fails with -EINVAL and still leaves every fb_display[i].mode dangling; the next console switch reads the freed fb_videomode in fb_videomode_to_var(). Test fb_count before touching the list. fbcon takes a reference through fbcon_open(), so that condition covers exactly the states in which fb_display[] points into the list, and the errno returned to userspace is unchanged. BUG: KASAN: slab-use-after-free in fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905) Read of size 4 at addr ffff8880107b449c by task kworker/1:1/47 Workqueue: events console_callback Call Trace: fb_videomode_to_var (drivers/video/fbdev/core/modedb.c:905) display_to_var (drivers/video/fbdev/core/fbcon.c:998) fbcon_switch (drivers/video/fbdev/core/fbcon.c:2182) redraw_screen (drivers/tty/vt/vt.c:994) complete_change_console (drivers/tty/vt/vt_ioctl.c:1141) console_callback (drivers/tty/vt/vt.c:3358) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... The buggy address is located 28 bytes inside of freed 96-byte region [ffff8880107b4480, ffff8880107b44e0) Cc: stable@vger.kernel.org Fixes: 7d9485e2c53c ("Staging: udlfb: Add functions to expose sysfs metrics and controls") Reported-by: co+ed9902f2e44184d9@bugs.sh Closes: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/ Assisted-by: Claude:claude-opus-5 Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://lore.kernel.org/all/1jSCSNaDKmuUG7h40rTsSl1rMaSwdlJef4rp%40bugs.sh/ Signed-off-by: Helge Deller <deller@gmx.de>
2026-10-13fbdev: sh_mobile_lcdcfb: Restore the per-overlay sysfs attributesKarl Mehltretter
The ovl_* files documented in Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb no longer exist. Commit a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver core") moved the attributes from each overlay's framebuffer device to the platform driver's dev_groups and renamed them overlay_*. There is now only one set of attributes for the whole LCDC. The callbacks still expect dev_get_drvdata() to return a struct fb_info, but the platform device holds struct sh_mobile_lcdc_priv, so they access the wrong structure. Restore the documented names and register the group on each overlay's framebuffer device with device_add_groups(). Remove it with device_remove_groups() before unregistering the framebuffer. Skip creation when dev_of_fbinfo(info) is NULL, as the old device_create_file() calls did. Drop the CONFIG_FB_DEVICE guard, since the driver already depends on it. Fixes: a979182a2453 ("fbdev: lcdcfb: Register sysfs groups through driver core") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de>