summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-14fs: move initializing f_mode before file_ref_init()Amir Goldstein
The comment above file_ref_init() says: "We're SLAB_TYPESAFE_BY_RCU so initialize f_ref last." but file_set_fsnotify_mode() was added after file_ref_init(). Move it right after setting f_mode, where it makes more sense. Fixes: 711f9b8fbe4f4 ("fsnotify: disable pre-content and permission events by default") Signed-off-by: Amir Goldstein <amir73il@gmail.com> Link: https://patch.msgid.link/20260109211536.3565697-1-amir73il@gmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14exportfs: Complete kernel-doc for struct export_operationsAndré Almeida
Write down the missing members definitions for struct export_operations, using as a reference the commit messages that created the members. Signed-off-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260112-tonyk-fs_uuid-v1-3-acc1889de772@igalia.com Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14exportfs: Mark struct export_operations functions at kernel-docAndré Almeida
Adding a `@` before the function names make then recognizable as kernel-docs, so they get correctly rendered in the documentation. Even if they are already marked with `@` in the short one-line summary, the kernel-docs will correctly favor the more detailed definition here. Signed-off-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260112-tonyk-fs_uuid-v1-2-acc1889de772@igalia.com Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14exportfs: Fix kernel-doc output for get_name()André Almeida
Without a space between %NAME_MAX and the plus sign, kernel-doc will output ``NAME_MAX``+1, which scapes the last backtick and make Sphinx format a much larger string as monospaced text. Signed-off-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260112-tonyk-fs_uuid-v1-1-acc1889de772@igalia.com Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14acct(2): begin the deprecation of legacy BSD process accountingJeff Layton
As Christian points out [1], even though it's privileged, this interface has a lot of footguns. There are better options these days (e.g. eBPF), so it would be good to start discouraging its use and mark it as deprecated. [1]: https://lore.kernel.org/linux-fsdevel/20250212-giert-spannend-8893f1eaba7d@brauner/ Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20260106-bsd-acct-v1-1-d15564b52c83@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14device_cgroup: remove branch hint after code refactorBreno Leitao
commit 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") reordered the checks in devcgroup_inode_permission() to check the inode mode before checking i_rdev, for better cache behavior. However, the likely() annotation on the i_rdev check was not updated to reflect the new code flow. Originally, when i_rdev was checked first, likely(!inode->i_rdev) made sense because most inodes were(?) regular files/directories, thus i_rdev == 0. After the reorder, by the time we reach the i_rdev check, we have already confirmed the inode IS a block or character device. Block and character special files are precisely defined by having a device number (i_rdev), so !inode->i_rdev is now the rare edge case, not the common case. Branch profiling confirmed this is 100% mispredicted: correct incorrect % Function File Line ------- --------- - -------- ---- ---- 0 2631904 100 devcgroup_inode_permission device_cgroup.h 24 Remove likely() to avoid giving the wrong hint to the CPU. Fixes: 4ef4ac360101 ("device_cgroup: avoid access to ->i_rdev in the common case in devcgroup_inode_permission()") Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260107-likely_device-v1-1-0c55f83a7e47@debian.org Reviewed-by: Mateusz Guzik <mjguzik@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14x86/traps: Print unhashed pointers on stack overflowRyosuke Yasuoka
When a stack overflow occurs, the kernel prints hashed fault address and the stack range using %p. The actual addresses are required for debugging and hashed pointers provide no useful information in this context. Use %px to print the unhashed, raw addresses. Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251224070735.454816-1-ryasuoka@redhat.com
2026-01-14Merge patch series "iomap: erofs page cache sharing preliminaries"Christian Brauner
Bring in the two changes needed in iomap and erofs to enable the page cache sharing work. * patches from https://patch.msgid.link/20260109102856.598531-1-lihongbo22@huawei.com: erofs: hold read context in iomap_iter if needed iomap: stash iomap read ctx in the private field of iomap_iter Link: https://patch.msgid.link/20260109102856.598531-1-lihongbo22@huawei.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14erofs: hold read context in iomap_iter if neededHongbo Li
Introduce `struct erofs_iomap_iter_ctx` to hold both `struct page *` and `void *base`, avoiding bogus use of `kmap_to_page()` in `erofs_iomap_end()`. With this change, fiemap and bmap no longer need to read inline data. Additionally, the upcoming page cache sharing mechanism requires passing the backing inode pointer to `erofs_iomap_{begin,end}()`, as I/O accesses must apply to backing inodes rather than anon inodes. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20260109102856.598531-3-lihongbo22@huawei.com Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14iomap: stash iomap read ctx in the private field of iomap_iterHongbo Li
It's useful to get filesystem-specific information using the existing private field in the @iomap_iter passed to iomap_{begin,end} for advanced usage for iomap buffered reads, which is much like the current iomap DIO. For example, EROFS needs it to: - implement an efficient page cache sharing feature, since iomap needs to apply to anon inode page cache but we'd like to get the backing inode/fs instead, so filesystem-specific private data is needed to keep such information; - pass in both struct page * and void * for inline data to avoid kmap_to_page() usage (which is bogus). Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20260109102856.598531-2-lihongbo22@huawei.com Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14nvme: fix PCIe subsystem reset controller state transitionNilay Shroff
The commit d2fe192348f9 (“nvme: only allow entering LIVE from CONNECTING state”) disallows controller state transitions directly from RESETTING to LIVE. However, the NVMe PCIe subsystem reset path relies on this transition to recover the controller on PowerPC (PPC) systems. On PPC systems, issuing a subsystem reset causes a temporary loss of communication with the NVMe adapter. A subsequent PCIe MMIO read then triggers EEH recovery, which restores the PCIe link and brings the controller back online. For EEH recovery to proceed correctly, the controller must transition back to the LIVE state. Due to the changes introduced by commit d2fe192348f9 (“nvme: only allow entering LIVE from CONNECTING state”), the controller can no longer transition directly from RESETTING to LIVE. As a result, EEH recovery exits prematurely, leaving the controller stuck in the RESETTING state. Fix this by explicitly transitioning the controller state from RESETTING to CONNECTING and then to LIVE. This satisfies the updated state transition rules and allows the controller to be successfully recovered on PPC systems following a PCIe subsystem reset. Cc: stable@vger.kernel.org Fixes: d2fe192348f9 ("nvme: only allow entering LIVE from CONNECTING state") Reviewed-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2026-01-14usb: gadget: uvc: retry vb2_reqbufs() with vb_vmalloc_memops if use_sg failXu Yang
Based on the reality[1][2] that vb2_dma_sg_alloc() can't alloc buffer with device DMA limits, those device will always get below error: "swiotlb buffer is full (sz: 393216 bytes), total 65536 (slots), used 2358 (slots)" and the uvc gadget function can't work at all. The videobuf2-dma-sg.c driver doesn't has a formal improve about this issue till now. For UVC gadget, the videobuf2 subsystem doesn't do dma_map() on vmalloc returned big buffer when allocate the video buffers, however, it do it for dma_sg returned buffer. So the issue happens for vb2_dma_sg_alloc(). To workaround the issue, lets retry vb2_reqbufs() with vb_vmalloc_memops if it fails to allocate buffer with vb2_dma_sg_memops. If use vmalloced buffer, UVC gadget will allocate some small buffers for each usb_request to do dma transfer, then uvc driver will memcopy data from big buffer to small buffer. Link[1]: https://lore.kernel.org/linux-media/20230828075420.2009568-1-anle.pan@nxp.com/ Link[2]: https://lore.kernel.org/linux-media/20230914145812.12851-1-hui.fang@nxp.com/ Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260113-uvc-gadget-fix-patch-v2-4-62950ef5bcb5@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: uvc: return error from uvcg_queue_init()Xu Yang
uvcg_queue_init() may fail, but its return value is currently ignored. Propagate the error code from uvcg_queue_init() to correctly report initialization failures. Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260113-uvc-gadget-fix-patch-v2-3-62950ef5bcb5@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: uvc: fix interval_duration calculationXu Yang
According to USB specification: For full-/high-speed isochronous endpoints, the bInterval value is used as the exponent for a 2^(bInterval-1) value. To correctly convert bInterval as interval_duration: interval_duration = 2^(bInterval-1) * frame_interval Because the unit of video->interval is 100ns, add a comment info to make it clear. Fixes: 48dbe731171e ("usb: gadget: uvc: set req_size and n_requests based on the frame interval") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260113-uvc-gadget-fix-patch-v2-2-62950ef5bcb5@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: uvc: fix req_payload_size calculationXu Yang
Current req_payload_size calculation has 2 issue: (1) When the first time calculate req_payload_size for all the buffers, reqs_per_frame = 0 will be the divisor of DIV_ROUND_UP(). So the result is undefined. This happens because VIDIOC_STREAMON is always executed after VIDIOC_QBUF. So video->reqs_per_frame will be 0 until VIDIOC_STREAMON is run. (2) The buf->req_payload_size may be bigger than max_req_size. Take YUYV pixel format as example: If bInterval = 1, video->interval = 666666, high-speed: video->reqs_per_frame = 666666 / 1250 = 534 720p: buf->req_payload_size = 1843200 / 534 = 3452 1080p: buf->req_payload_size = 4147200 / 534 = 7766 Based on such req_payload_size, the controller can't run normally. To fix above issue, assign max_req_size to buf->req_payload_size when video->reqs_per_frame = 0. And limit buf->req_payload_size to video->req_size if it's large than video->req_size. Since max_req_size is used at many place, add it to struct uvc_video and set the value once endpoint is enabled. Fixes: 98ad03291560 ("usb: gadget: uvc: set req_length based on payload by nreqs instead of req_size") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260113-uvc-gadget-fix-patch-v2-1-62950ef5bcb5@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: dwc3: apple: Ignore USB role switches to the active roleJanne Grunau
Ignore USB role switches if dwc3-apple is already in the desired state. The USB-C port controller on M2 and M1/M2 Pro/Max/Ultra devices issues additional interrupts which result in USB role switches to the already active role. Ignore these USB role switches to ensure the USB-C port controller and dwc3-apple are always in a consistent state. This matches the behaviour in __dwc3_set_mode() in core.c. Fixes detecting USB 2.0 and 3.x devices on the affected systems. The reset caused by the additional role switch appears to leave the USB devices in a state which prevents detection when the phy and dwc3 is brought back up again. Fixes: 0ec946d32ef7 ("usb: dwc3: Add Apple Silicon DWC3 glue layer driver") Cc: stable <stable@kernel.org> Signed-off-by: Janne Grunau <j@jannau.net> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Sven Peter <sven@kernel.org> Tested-by: Sven Peter <sven@kernel.org> # M1 mac mini and macbook air Link: https://patch.msgid.link/20260109-apple-dwc3-role-switch-v1-1-11623b0f6222@jannau.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14drm/xe/mert: Improve handling of MERT CAT errorsMichal Wajdeczko
All MERT catastrophic errors but VF's LMTT fault are serious, so we shouldn't limit our handling only to print debug messages. Change CATERR message to error level and then declare the device as wedged to match expectation from the design document. For the LMTT faults, add a note about adding tracking of this unexpected VF activity. While at it, rename register fields defnitions to match the BSpec. Also drop trailing include guard name from the regs.h file. BSpec: 74625 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com> Link: https://patch.msgid.link/20260112183716.28700-1-michal.wajdeczko@intel.com
2026-01-14usb: host: xhci-tegra: Use platform_get_irq_optional() for wake IRQsWayne Chang
When some wake IRQs are disabled in the device tree, the corresponding interrupt entries are removed from DT. In such cases, the driver currently calls platform_get_irq(), which returns -ENXIO and logs an error like: tegra-xusb 3610000.usb: error -ENXIO: IRQ index 2 not found However, not all wake IRQs are mandatory. The hardware can operate normally even if some wake sources are not defined in DT. To avoid this false alarm and allow missing wake IRQs gracefully, use platform_get_irq_optional() instead of platform_get_irq(). Fixes: 5df186e2ef11 ("usb: xhci: tegra: Support USB wakeup function for Tegra234") Cc: stable <stable@kernel.org> Signed-off-by: Wayne Chang <waynec@nvidia.com> Signed-off-by: Wei-Cheng Chen <weichengc@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260112145653.95691-1-weichengc@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14USB: OHCI/UHCI: Add soft dependencies on ehci_platformHuacai Chen
Commit 9beeee6584b9aa4f ("USB: EHCI: log a warning if ehci-hcd is not loaded first") said that ehci-hcd should be loaded before ohci-hcd and uhci-hcd. However, commit 05c92da0c52494ca ("usb: ohci/uhci - add soft dependencies on ehci_pci") only makes ohci-pci/uhci-pci depend on ehci- pci, which is not enough and we may still see the warnings in boot log. To eliminate the warnings we should make ohci-hcd/uhci-hcd depend on ehci-hcd. But Alan said that the warning introduced by 9beeee6584b9aa4f is bogus, we only need the soft dependencies in the PCI level rather than the HCD level. However, there is really another neccessary soft dependencies between ohci-platform/uhci-platform and ehci-platform, which is added by this patch. The boot logs are below. 1. ohci-platform loaded before ehci-platform: ohci-platform 1f058000.usb: Generic Platform OHCI controller ohci-platform 1f058000.usb: new USB bus registered, assigned bus number 1 ohci-platform 1f058000.usb: irq 28, io mem 0x1f058000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 4 ports detected Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after usb 1-4: new low-speed USB device number 2 using ohci-platform ehci-platform 1f050000.usb: EHCI Host Controller ehci-platform 1f050000.usb: new USB bus registered, assigned bus number 2 ehci-platform 1f050000.usb: irq 29, io mem 0x1f050000 ehci-platform 1f050000.usb: USB 2.0 started, EHCI 1.00 usb 1-4: device descriptor read/all, error -62 hub 2-0:1.0: USB hub found hub 2-0:1.0: 4 ports detected usb 1-4: new low-speed USB device number 3 using ohci-platform input: YSPRINGTECH USB OPTICAL MOUSE as /devices/platform/bus@10000000/1f058000.usb/usb1/1-4/1-4:1.0/0003:10C4:8105.0001/input/input0 hid-generic 0003:10C4:8105.0001: input,hidraw0: USB HID v1.11 Mouse [YSPRINGTECH USB OPTICAL MOUSE] on usb-1f058000.usb-4/input0 2. ehci-platform loaded before ohci-platform: ehci-platform 1f050000.usb: EHCI Host Controller ehci-platform 1f050000.usb: new USB bus registered, assigned bus number 1 ehci-platform 1f050000.usb: irq 28, io mem 0x1f050000 ehci-platform 1f050000.usb: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 4 ports detected ohci-platform 1f058000.usb: Generic Platform OHCI controller ohci-platform 1f058000.usb: new USB bus registered, assigned bus number 2 ohci-platform 1f058000.usb: irq 29, io mem 0x1f058000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 4 ports detected usb 2-4: new low-speed USB device number 2 using ohci-platform input: YSPRINGTECH USB OPTICAL MOUSE as /devices/platform/bus@10000000/1f058000.usb/usb2/2-4/2-4:1.0/0003:10C4:8105.0001/input/input0 hid-generic 0003:10C4:8105.0001: input,hidraw0: USB HID v1.11 Mouse [YSPRINGTECH USB OPTICAL MOUSE] on usb-1f058000.usb-4/input0 In the later case, there is no re-connection for USB-1.0/1.1 devices, which is expected. Cc: stable <stable@kernel.org> Reported-by: Shengwen Xiao <atzlinux@sina.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/20260112084802.1995923-1-chenhuacai@loongson.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: dwc3: apple: Set USB2 PHY mode before dwc3 initSven Peter
Now that the upstream code has been getting broader test coverage by our users we occasionally see issues with USB2 devices plugged in during boot. Before Linux is running, the USB2 PHY has usually been running in device mode and it turns out that sometimes host->device or device->host transitions don't work. The root cause: If the role inside the USB2 PHY is re-configured when it has already been powered on or when dwc3 has already enabled the ULPI interface the new configuration sometimes doesn't take affect until dwc3 is reset again. Fix this rare issue by configuring the role much earlier. Note that the USB3 PHY does not suffer from this issue and actually requires dwc3 to be up before the correct role can be configured there. Reported-by: James Calligeros <jcalligeros99@gmail.com> Reported-by: Janne Grunau <j@jannau.net> Fixes: 0ec946d32ef7 ("usb: dwc3: Add Apple Silicon DWC3 glue layer driver") Cc: stable <stable@kernel.org> Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Janne Grunau <j@jannau.net> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@kernel.org> Link: https://patch.msgid.link/20260109-dwc3-apple-usb2phy-fix-v2-1-ab6b041e3b26@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke()Mario Peter
The ChipIdea UDC driver can encounter "not page aligned sg buffer" errors when a USB device is reconnected after being disconnected during an active transfer. This occurs because _ep_nuke() returns requests to the gadget layer without properly unmapping DMA buffers or cleaning up scatter-gather bounce buffers. Root cause: When a disconnect happens during a multi-segment DMA transfer, the request's num_mapped_sgs field and sgt.sgl pointer remain set with stale values. The request is returned to the gadget driver with status -ESHUTDOWN but still has active DMA state. If the gadget driver reuses this request on reconnect without reinitializing it, the stale DMA state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero num_mapped_sgs) and attempt to use freed/invalid DMA addresses, leading to alignment errors and potential memory corruption. The normal completion path via _hardware_dequeue() properly calls usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before returning the request. The _ep_nuke() path must do the same cleanup to ensure requests are returned in a clean, reusable state. Fix: Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror the cleanup sequence in _hardware_dequeue(): - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set - Call sglist_do_debounce() with copy=false if bounce buffer exists This ensures that when requests are returned due to endpoint shutdown, they don't retain stale DMA mappings. The 'false' parameter to sglist_do_debounce() prevents copying data back (appropriate for shutdown path where transfer was aborted). Signed-off-by: Mario Peter <mario.peter@leica-geosystems.com> Reviewed-by: Xu Yang <xu.yang_2@nxp.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://patch.msgid.link/20260108165902.795354-1-mario.peter@leica-geosystems.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: chipidea: ci_hdrc_imx: use "wakeup" suffix for wakeup interrupt nameXu Yang
Currently the wakeup and controller interrupt name are same. It's not easy to find the correct one in /proc/interrupt at the first glance. Rename the wakeup interrupt name for better distinction. Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://patch.msgid.link/20260112110408.3263954-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: dwc3: Always deassert xilinx resetsSean Anderson
If we don't have a usb3 phy we don't need to assert the core resets. Deassert them even if we didn't assert them to support booting when the bootloader never released the core from reset. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://patch.msgid.link/20260106171018.501612-1-sean.anderson@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: u_ether: use <linux/hex.h> header fileRandy Dunlap
Since <linux/kernel.h> no longer includes <linux/hex.h>, any users of the hex interfaces need to include <linux/hex.h> themselves, so add the header file here as needed. Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: e065c6a7e46c ("usb: gadget: u_ether: add gether_opts for config caching") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/linux-next/2768c835-7ac9-4540-a665-5dd516a80eee@infradead.org/T/#t Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260113071831.4158296-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14USB: HCD: remove logic about which hcd is loadedGreg Kroah-Hartman
It turns out that warning about which USB host controller is loaded before another one doesn't really matter. All that really is needed is the PCI softdep module loading logic, which has been present in the kernel ever since commit 05c92da0c524 ("usb: ohci/uhci - add soft dependencies on ehci_pci") So remove the warning messages, they are not useful, not needed, and only confuse people. As can be seen in the discussion at https://lore.kernel.org/r/20251230080014.3934590-1-chenhuacai@loongson.cn Cc: Huacai Chen <chenhuacai@loongson.cn> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://patch.msgid.link/2026010739-diffuser-shelter-e31c@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: dwc3: imx8mp: disable auto suspend for host roleXu Yang
Do dwc3 core auto suspend enable for device and disable for host , this can make sure dwc3 core device auto suspend setting is correct all the time, the background of disable dwc3 core device auto suspend is to make its parent device suspend immediately (so wakeup enable can be enabled) after xhci-plat device suspended, for device mode, we keep the dwc3 core device auto suspend is to give some wait for gadget to be enumerated. Note: It's a temporary solution until we switch to using the new flatten model. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260108081433.2119328-3-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: dwc3: imx8mp: rename dwc3 to dwc3_pdev in struct dwc3_imx8mpXu Yang
It's confuse to let "dwc3" represent a platform_device, because "dwc3" may also represent a dwc3 core structure. Rename it for better distinction. Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260108081433.2119328-2-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: dwc3: drd: extend dwc3_pre_set_role() to extcon and otg usecaseXu Yang
Call dwc3_pre_set_role() to support both extcon and otg usecase, so that the glue driver can do proper action in case of role changes. Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20260108081433.2119328-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: f_fs: fix DMA-BUF OUT queuesSam Day
Currently, DMA_FROM_DEVICE is used when attaching DMABUFs to IN endpoints and DMA_TO_DEVICE for OUT endpoints. This is inverted from how it should be. The result is IOMMU read-only mappings placed on OUT queues, triggering arm-smmu write faults. Put differently, OUT endpoints flow data from host -> gadget, meaning the UDC peripheral needs to have write access to the buffer to fill it with the incoming data. This commit flips the directions and updates the implicit-sync helpers so IN endpoints act as readers and OUT endpoints as writers. Signed-off-by: Sam Day <me@samcday.com> Tested-by: David Heidelberg <david@ixit.cz> # OnePlus 6T on sdm845-next-20251119 Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-2-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: f_fs: Fix ioctl error handlingSam Day
When ffs_epfile_ioctl handles FUNCTIONFS_DMABUF_* ioctls, it's currently falling through when copy_from_user fails. However, this fallthrough isn't being checked properly, so the handler continues executing further than it should. It then tries the secondary dispatch where it ultimately gives up and returns -ENOTTY. The end result is invalid ioctl invocations will yield a -ENOTTY rather than an -EFAULT. It's a common pattern elsewhere in the kernel code to directly return -EFAULT when copy_from_user fails. So we update ffs_epfile_ioctl to do the same and fix this issue. Signed-off-by: Sam Day <me@samcday.com> Link: https://patch.msgid.link/20260108-ffs-dmabuf-ioctl-fix-v1-1-e51633891a81@samcday.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14usb: gadget: f_tcm: initialize data_len in UAS path for consistencyJiasheng Jiang
In usbg_submit_command(), which handles the UAS protocol, the 'data_len' member of the 'usbg_cmd' structure was left uninitialized by the logic, relying instead on the zeroing performed by usbg_get_cmd(). In contrast, the BOT path (bot_submit_command) explicitly initializes this field from the Command Block Wrapper (CBW). This discrepancy is evident in error handling paths where __target_init_cmd() is called using cmd->data_len. Explicitly initialize cmd->data_len to 0 in the UAS path and use this variable when calling target_submit_cmd(). This ensures architectural consistency between the UAS and BOT protocols within the driver and avoids reliance on implicit memory state during error transitions. Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://patch.msgid.link/20260107190622.26070-1-jiashengjiangcool@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-14i3c: Move device name assignment after i3c_bus_initBilly Tsai
Move device name initialization to occur after i3c_bus_init() so that i3cbus->id is guaranteed to be assigned before it is used. Fixes: 9d4f219807d5 ("i3c: fix refcount inconsistency in i3c_master_register") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260112-upstream_i3c_fix-v1-1-cbbf2cb71809@aspeedtech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: renesas: Add suspend/resume supportTommaso Merciai
The Renesas I3C controller does not retain its register state across system suspend, requiring the driver to explicitly save and restore hardware configuration. Add suspend and resume NOIRQ callbacks to handle system sleep transitions. During suspend, save the Device Address Table (DAT) entries, assert reset lines, and disable all related clocks to allow the controller to enter a low-power state. On resume, re-enable clocks and reset lines in the proper order. Restore the REFCKCTL register, master dynamic address, and all DAT entries, then reinitialize the controller. Store the REFCLK divider value, and the master dynamic address to restore timing and addressing configuration after resume. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/c469ef89e0156d37746a85bfc314232847d1185a.1767781092.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: renesas: Factor out hardware initialization to separate functionTommaso Merciai
Move the hardware initialization sequence in renesas_i3c_bus_init() into a dedicated renesas_i3c_hw_init() helper. Simplify the code and prepare the driver for upcoming suspend/resume support. No functional change intended. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/795327270a6ceb23e15513a2619a19ae4876cfba.1767781092.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: renesas: Store clock rate and reset controls in struct renesas_i3cTommaso Merciai
Update the struct renesas_i3c to store the clock rate, presetn and tresetn handlers. Replace local usage of the clock rate and reset controls with these structure fields. Simplify the code and prepare the driver for upcoming suspend/resume support. No functional change intended. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/9e1da95dd9137590c752ecd9429925afcbeb918b.1767781092.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: renesas: Switch to clk_bulk API and store clocks in private dataTommaso Merciai
Replace individual devm_clk_get_enabled() calls with the clk_bulk API and store the clock handles in the driver's private data structure. All clocks required by the controller are now acquired and enabled using devm_clk_bulk_get_all_enabled(), removing the need for per-SoC clock handling and the renesas_i3c_config data. The TCLK is accessed via a fixed index in the bulk clock array. Simplify the code and prepare the driver for upcoming suspend/resume support. No functional change intended. Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/1286f8600b542da55facf9920fed7c06b2b0e4d5.1767781092.git.tommaso.merciai.xr@bp.renesas.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Define Multi-Bus instances for supported controllersAdrian Hunter
Define Multi-Bus Instances at offset 0x400 for Intel controllers. Intel SoCs include two I3C PCI devices in the Low Power Subsystem (LPSS), each capable of hosting two I3C buses. Panther Lake and Wildcat Lake support three buses in total (IDs 0–2), while Nova Lake supports four (IDs 0–3). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-12-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Add support for Multi-Bus InstancesAdrian Hunter
Add support for MIPI I3C Host Controllers with the Multi-Bus Instance capability. These controllers can host multiple I3C buses (up to 15) within a single hardware function (e.g., PCIe B/D/F), providing one indepedent HCI register set and corresponding I3C bus controller logic per bus. Create an MFD cell for each instance and use platform_data to pass the starting address of the instance's register set. The MIPI I3C HCI specification defines an Extended Capability that holds the offset of each instance register set. Parsing this information is relatively complex, so include the offsets in driver data for now. Driver data for additional instances beyond instance 0 will be added in a subsequent patch. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-11-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Convert to MFD driverAdrian Hunter
Prepare for Multi-Bus instance support. Convert to MFD driver but still support only 1 instance. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-10-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Pass base regs as platform data to i3c core deviceAdrian Hunter
Use the parent's MMIO mapping for multi-bus instances to avoid overlapping regions. These instances share the same MMIO address space, but the ranges are not guaranteed to be contiguous. By passing base_regs from the parent mapping, child devices can access their registers without creating conflicting mappings. Prepare for multi-bus instance support by passing base_regs to child devices. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-9-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci: Allow for Multi-Bus InstancesAdrian Hunter
Add support for MIPI I3C Host Controllers with the Multi-Bus Instance capability. These controllers can host multiple I3C buses (up to 15) within a single hardware function (e.g., PCIe B/D/F), providing one indepedent HCI register set and corresponding I3C bus controller logic per bus. A separate platform device will represent each instance, but it is necessary to allow for shared resources. Multi-bus instances share the same MMIO address space, but the ranges are not guaranteed to be contiguous. To avoid overlapping mappings, pass base_regs from the parent mapping to child devices. Allow the IRQ to be shared among instances. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-8-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Assign unique device names and IDs for Intel LPSS I3CAdrian Hunter
Simplify the code and ensure names and IDs align with device documentation. Use explicit device names and IDs for Intel LPSS I3C controllers instead of dynamically allocated values. Add "intel-lpss-i3c" to the platform_device_id table in the mipi-i3c-hci driver and use the same name for Intel I3C controllers in the mipi_i3c_hci_pci driver. Assign hard-coded IDs to reflect the hardware layout. Intel SoCs include two I3C PCI devices in the Low Power Subsystem (LPSS), each supporting up to two I3C buses. The second PCI device is assigned ID 2 (not 1) to match this topology. Additional IDs will be introduced when Multi-Bus Instance support is implemented. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-7-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Enable MSI supportAdrian Hunter
Enable MSI support by using pci_alloc_irq_vectors() to request all supported IRQ types. Do not call pci_free_irq_vectors() because for resource-managed devices (those initialized with pcim_enable_device()), IRQ vector allocation is automatically managed. See pci_setup_msi_context() and pcim_setup_msi_release() for details. Note: The current documentation for pci_alloc_irq_vectors() does not mention this behavior. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-6-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci-pci: Do not repeatedly check for NULL driver_dataAdrian Hunter
All entries in the id_table have driver_data. Do not repeatedly check for NULL driver_data. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-5-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci: Quieten initialization messagesAdrian Hunter
The copious initialization messages are at most useful only for debugging. Change them from dev_info() or dev_notice() to dev_dbg(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-4-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci: Stop reading Extended Capabilities if capability ID is 0Adrian Hunter
Extended Capability ID value 0 is special. It signifies the end of the list. Stop reading Extended Capabilities if capability ID is 0. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-3-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: mipi-i3c-hci: Remove duplicate blank linesAdrian Hunter
Remove duplicate blank lines from mipi-i3c-hci code. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260106164416.67074-2-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: Add stub functions when I3C support is disabledFrank Li
When I3C is disabled, unused functions are removed by the linker because the driver relies on regmap and no I3C devices are registered, so normal I3C paths are never called. However, some drivers may still call low-level I3C transfer helpers. Provide stub implementations to avoid adding conditional ifdefs everywhere. Add stubs for i3c_device_do_xfers() and i3c_device_get_supported_xfer_mode() only. Other stubs will be introduced when they are actually needed. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512230418.nu3V6Yua-lkp@intel.com/ Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251230145718.4088694-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: master: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251224124551.208778-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-01-14i3c: master: svc: Initialize 'dev' to NULL in svc_i3c_master_ibi_isr()Frank Li
Initialize the 'dev' pointer to NULL in svc_i3c_master_ibi_isr() and add a NULL check in the error path. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202512131016.YCKIsDXM-lkp@intel.com/ Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251215200852.3079073-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-17 23:55:51 +0000