linux/drivers/misc, branch rpi-mipi

misc: rp1-pio: Don't just reuse the same DMA buf

2025-06-23T13:52:25Z

A missing pointer increment meant that not only was the same buffer being reused again and again, there was also no protection against using it simultaneously for multiple transfers. Fix that basic bug, and also move a similar increment to before the transfer is started, which feels less racy. See: https://github.com/raspberrypi/linux/issues/6919 Signed-off-by: Phil Elwell

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-06-23T09:56:26Z

VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify

2025-06-19T13:32:34Z

commit 1bd6406fb5f36c2bb1e96e27d4c3e9f4d09edde4 upstream. During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast. Fixes: a1d88436d53a ("VMCI: Fix two UVA mapping bugs") Cc: stable Closes: https://lore.kernel.org/all/e91da589-ad57-3969-d979-879bbd10dddd@huawei.com/ Signed-off-by: Wupeng Ma Link: https://lore.kernel.org/r/20250510033040.901582-1-mawupeng1@huawei.com Signed-off-by: Greg Kroah-Hartman

mei: vsc: Cast tx_buf to (__be32 *) when passed to cpu_to_be32_array()

2025-06-19T13:32:13Z

[ Upstream commit 97ce0fe2b7240d47d9124daa92217e478c21a3ba ] Commit f88c0c72ffb0 ("mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type") changed the type of tx_buf from "void *" to "struct vsc_tp_packet *" and added a cast to (u32 *) when passing it to cpu_to_be32_array() and the same change was made for rx_buf. This triggers the type-check warning in sparse: vsc-tp.c:327:28: sparse: expected restricted __be32 [usertype] *dst vsc-tp.c:327:28: sparse: got unsigned int [usertype] * vsc-tp.c:343:42: sparse: expected restricted __be32 const [usertype] *src vsc-tp.c:343:42: sparse: got unsigned int [usertype] * Fix this by casting to (__be32 *) instead. Note actually changing the type of the buffers to "be32 *" is not an option this buffer does actually contain a "struct vsc_tp_packet" and is used as such most of the time. vsc_tp_rom_xfer() re-uses the buffers as just dumb arrays of 32 bit words to talk to the device before the firmware has booted, to avoid needing to allocate a separate buffer. Fixes: f88c0c72ffb0 ("mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505071634.kZ0I7Va6-lkp@intel.com/ Signed-off-by: Hans de Goede Reviewed-by: Sakari Ailus Link: https://lore.kernel.org/r/20250507090728.115910-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-06-03T14:15:42Z

eeprom: ee1004: Check chip before probing

2025-05-29T09:02:43Z

[ Upstream commit d9406677428e9234ea62bb2d2f5e996d1b777760 ] Like other eeprom drivers, check if the device is really there and functional before probing. Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20250218220959.721698-1-eajames@linux.ibm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

misc: pci_endpoint_test: Give disabled BARs a distinct error code

2025-05-29T09:02:25Z

[ Upstream commit 7e80bbef1d697dbce7a39cfad0df770880fe3f29 ] The current code returns -ENOMEM if test->bar[barno] is NULL. There can be two reasons why test->bar[barno] is NULL: 1) The pci_ioremap_bar() call in pci_endpoint_test_probe() failed. 2) The BAR was skipped, because it is disabled by the endpoint. Many PCI endpoint controller drivers will disable all BARs in their init function. A disabled BAR will have a size of 0. A PCI endpoint function driver will be able to enable any BAR that is not marked as BAR_RESERVED (which means that the BAR should not be touched by the EPF driver). Thus, perform check if the size is 0, before checking if test->bar[barno] is NULL, such that we can return different errors. This will allow the selftests to return SKIP instead of FAIL for disabled BARs. Signed-off-by: Niklas Cassel Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250123120147.3603409-3-cassel@kernel.org Signed-off-by: Manivannan Sadhasivam [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin

mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type

2025-05-29T09:01:58Z

[ Upstream commit f88c0c72ffb014e5eba676ee337c4eb3b1d6a119 ] vsc_tp.tx_buf and vsc_tp.rx_buf point to a struct vsc_tp_packet, use the correct type instead of "void *" and use sizeof(*ptr) when allocating memory for these buffers. Signed-off-by: Hans de Goede Reviewed-by: Alexander Usyskin Reviewed-by: Sakari Ailus Link: https://lore.kernel.org/r/20250318141203.94342-3-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y

2025-05-06T13:14:05Z

objtool, lkdtm: Obfuscate the do_nothing() pointer

2025-05-02T05:59:20Z

[ Upstream commit 05026ea01e95ffdeb0e5ac8fb7fb1b551e3a8726 ] If execute_location()'s memcpy of do_nothing() gets inlined and unrolled by the compiler, it copies one word at a time: mov 0x0(%rip),%rax R_X86_64_PC32 .text+0x1374 mov %rax,0x38(%rbx) mov 0x0(%rip),%rax R_X86_64_PC32 .text+0x136c mov %rax,0x30(%rbx) ... Those .text references point to the middle of the function, causing objtool to complain about their lack of ENDBR. Prevent that by resolving the function pointer at runtime rather than build time. This fixes the following warning: drivers/misc/lkdtm/lkdtm.o: warning: objtool: execute_location+0x23: relocation to !ENDBR: .text+0x1378 Reported-by: kernel test robot Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Linus Torvalds Link: https://lore.kernel.org/r/30b9abffbddeb43c4f6320b1270fa9b4d74c54ed.1742852847.git.jpoimboe@kernel.org Closes: https://lore.kernel.org/oe-kbuild-all/202503191453.uFfxQy5R-lkp@intel.com/ Signed-off-by: Sasha Levin