summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-10-12drm/virtio: add ARGB8888 support for primary planesDorinda Bassey
Add DRM_FORMAT_HOST_ARGB8888 to the list of supported formats for virtio-gpu primary planes. Without this, glmark2-drm fails at startup because it selects ARGB visual configs by default, which don't match the XRGB-only plane capabilities. This causes drmModeSetCrtc to fail with EINVAL. The virtio_gpu_translate_format() function already handles ARGB8888 translation to VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM, so this just exposes the existing capability to userspace. Signed-off-by: Dorinda Bassey <dbassey@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260930132707.500748-1-dbassey@redhat.com
2026-10-12Revert "drm/virtio: Add pixel blend mode property to cursor plane"Dmitry Osipenko
The cursor blending mode was added twice because the same change was applied by accident from different patches. Revert the second patch. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/dri-devel/ce84d3d2-e78b-4939-aecf-9ef7267bd42a@samsung.com/ Fixes: 6947b78df4d2 ("drm/virtio: Add pixel blend mode property to cursor plane") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20261007222244.295186-1-dmitry.osipenko@collabora.com
2026-10-11netfilter: disable br_netfilter in user namespacesFlorian Westphal
br_netfilter has way too many bugs, schedule for removal and disable the feature in user namespaces. In particular, we get more and more gadgets to have bridge ports escape rcu_read_lock() protection, then underlying device gets reconfigured (macvlan or something else), then reinject into network stack causes crash because net_device is assumed to still have bridge rx data associated with it. br_netfilter is an ancient kludge that emulates ip stack from within the bridge and then calls into ipv4/ipv6 netfilter hooks to have bridged frames processed via iptables/ip6tables by setting the 'call-iptables' sysctls to 1. It is NOT related to ebtables or nftables 'bridge' family at all. Note that in addition to call-iptables, sysctls, the bridge also exposes call-iptables per bridge device via netlink and sysfs ('BROPT_NF_CALL_IPTABLES') toggles. Those are still available, the brnet structure is scoped to br_netfilter; exposing it bridge-wide is a big no-no. This relies on brnf_device_event() no longer registering the base br_netfilter hooks, so while BROPT_NF_CALL_IPTABLES can be set, it has no effect because the hooks that evaluate this feature bit are never registered. brnf_init_net can no longer depend on CONFIG_SYSCTL, else such builds never disable support in user namespaces. Cc: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Florian Westphal <fw@strlen.de> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2026-10-11dmaengine: ste_dma40: Preserve the LCPA I/O address spaceLinus Walleij
The LCPA area is mapped with devm_ioremap(), but lcpa_base and the per-channel lcpa pointer lack __iomem annotations. This loses the I/O address space and makes sparse warn when d40_current_addr() assigns LCPA register addresses to its __iomem pointers. Annotate both pointers and the LCPA argument of d40_log_lli_lcpa_write() to preserve the I/O address space from the mapping to the register accessors. This also fixes the existing LCPA read and write warnings without changing the generated code. Fixes: c80edceff29e ("dmaengine: ste_dma40: Fix cyclic transfer residue") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202610090216.pjMRxhRL-lkp@intel.com/ Assisted-by: LLM Signed-off-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20261010-dma40-smatch-fix-v1-1-26ca10043957@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-11docs: dmaengine: clarify ordering rules around cookie completionVinod Koul
Sashiko pointed in [1] about the cookie completion order. It is good to Document that for ensuring that dma buffer is flushed and no stale data is seeing by consumer, we need to make sure such action is taken before drivers invoke dma cookie completion. [1]: https://lore.kernel.org/r/20260917072507.5BDB61F000FF@smtp.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20261009093745.539924-1-vkoul@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-10-11Merge tag 'landlock-7.3-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux Pull Landlock fix from Mickaël Salaün: "This fixes a Clang bug by removing an annotation, which was introduced mostly for documentation" * tag 'landlock-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: landlock: Drop __counted_by from landlock_domain.handled_masks
2026-10-11Merge tag 'spi-fix-v7.3-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small collection of driver specific fixes, plus a new device ID in the DesignWare device tree binding. One of the sg2044 fixes which enforces clock limits properly is more critical than average since getting them wrong might lead to data corruption" * tag 'spi-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl2610 spi spi: sg2044-nor: Honor SPI clock limits spi: sg2044-nor: Return transfer errors spi: cadence-qspi: Fix status polling with octal DTR chips spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock
2026-10-11Merge tag 'regulator-fix-v7.3-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "There's a couple of core fixes here: there were a couple of issues with of_regulator_bulk_get_all() not behaving consistently with the other bulk regulator APIs which caused memory leaks and error handling issues in users. We also have a couple of fairly standard driver specific fixes" * tag 'regulator-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: ltc3676: don't read the write-only HRST and CLIRQ registers regulator: of: state who owns the array from of_regulator_bulk_get_all() regulator: of: fill in supply names in of_regulator_bulk_get_all() regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4
2026-10-11MAINTAINERS: add entry for the Rust `bug` moduleFUJITA Tomonori
Add a MAINTAINERS entry for the Rust `bug` module, which currently provides the `warn_on!` macro. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20261004124211.381401-1-tomo@flapping.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-10-11Merge tag 'rust-timekeeping-for-v7.4-rc1' of ↵Miguel Ojeda
https://github.com/Rust-for-Linux/linux into rust-next Pull timekeeping updates from Andreas Hindborg: - Warn and assert when passing out-of-range inputs to 'fsleep' and 'udelay'. - Rename 'ClockSource' to 'ClockId' to better align with naming conventions in C kernel. - Make 'CONFIG_HZ' value available as 'bindings::HZ'. - Add a conversion method to convert 'Delta' to 'jiffies' for use in timeout arguments. - Add implementation detail documentation for 'HrTimer'. * tag 'rust-timekeeping-for-v7.4-rc1' of https://github.com/Rust-for-Linux/linux: rust: hrtimer: document handle based design rationale rust: time: add Delta::to_jiffies_timeout() for timeout conversion rust: bindings: set HZ to CONFIG_HZ rust: time: rename ClockSource trait to ClockId rust: time: warn and assert out-of-range input in fsleep() and udelay()
2026-10-11Merge tag 'alloc-7.4-rc1' of https://github.com/Rust-for-Linux/linux into ↵Miguel Ojeda
rust-next Pull alloc updates from Danilo Krummrich: - Add Alice Ryhl as co-maintainer for Rust [ALLOC] - Allow different error types in KBox::pin_slice(), enabling use of infallible initializers - Add NumaNode::id() accessor to retrieve the underlying NUMA node identifier * tag 'alloc-7.4-rc1' of https://github.com/Rust-for-Linux/linux: rust: alloc: add `NumaNode::id()` accessor rust: alloc: allow different error types in `KBox::pin_slice` MAINTAINERS: add Alice Ryhl as co-maintainer for Rust [ALLOC]
2026-10-11Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Driver (and tape media changer) only fixes. Three of the fixes are about the same size, (ch, ufs decouble CQ and ufs avoid unsafe MMIO) but the unsafe MMIO is the least obvious logic change" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock() scsi: ch: Do not keep references to data transfer element devices scsi: ufs: mediatek: Handle mPHY power-on failures scsi: qedi: Initialize callback state before registration scsi: ufs: core: Hold a clock reference across the probe
2026-10-11bus: mhi: ep: clients: Add loopback driver for data path testingSumit Kumar
When an MHI endpoint device runs Linux, there is no firmware to implement the LOOPBACK channel echo that real modem firmware provides. Without an endpoint-side driver, the host loopback test has no software echo partner and cannot exercise the full end-to-end MHI data path. Add an endpoint-side loopback driver that binds to the LOOPBACK channel and echoes received data back to the host. An ordered workqueue is used for asynchronous processing to preserve packet ordering. Together with the host-side loopback driver, this enables complete MHI data path validation for Linux-based endpoint devices. Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com> Link: https://patch.msgid.link/20261005-lb-v7-3-36a268b6386f@oss.qualcomm.com [mani: fixed checkpatch warnings] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
2026-10-11bus: mhi: ep: Add mhi_ep_queue_buf() API for raw buffer queuingSumit Kumar
Some MHI endpoint clients do not use socket buffers and need a way to queue raw buffers for DL transfers. Add mhi_ep_queue_buf() to support this use case. Refactor mhi_ep_queue_skb() to delegate to a new internal mhi_ep_queue() helper shared by both APIs, and rename mhi_ep_skb_completion() to mhi_ep_buf_completion() to reflect its broader use. Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com> Link: https://patch.msgid.link/20261005-lb-v7-2-36a268b6386f@oss.qualcomm.com Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
2026-10-11bus: mhi: host: clients: Add loopback driver with sysfs interfaceSumit Kumar
The MHI specification defines a LOOPBACK channel. The endpoint firmware echoes back whatever the host sends on this channel. Without a host-side driver, there is no way to exercise this channel to validate MHI data path integrity between host and endpoint. Add a host-side loopback driver that binds to the LOOPBACK channel and expose a sysfs interface for data path testing. The sysfs interface allows users to configure TRE buffer size and count, trigger a loopback test, and read the result. The new sysfs ABI is documented under Documentation/ABI/testing/, not stable/, since this is a new interface without established API guarantees yet. It is unrelated to the existing stable MHI sysfs ABI documented in Documentation/ABI/stable/sysfs-bus-mhi, despite both being covered by the same MAINTAINERS entry. Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com> Link: https://patch.msgid.link/20261005-lb-v7-1-36a268b6386f@oss.qualcomm.com Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
2026-10-11bus: mhi: host: pci_generic: Add Quectel RM500Q-AE supportSteve Meek
The Quectel RM500Q-AE (SDX55) enumerates with the Qualcomm SDX55 ID 17cb:0306 and subsystem ID 17cb:5002, so it binds to the generic qcom-sdx55m entry. That configuration expects QMI on channels 14/15, which this module's firmware does not answer: the modem probes, but every QMI request over the control channel times out and no data session can be set up. Users of this module have had to fall back to Quectel's out-of-tree driver. Like the other Quectel modules, the RM500Q-AE provides MBIM control on channels 12/13 and data on IP_HW0_MBIM. Add an entry for its subsystem ID, which no other entry in the table uses, that reuses the Quectel em1xx channel configuration. The EDL image name is the one the generic SDX55 entry already uses. Tested on a Xunison Exigo D50 5G (IPQ5018) with modem firmware RM500QAEAAR13A03M4G: the modem probes as quectel-rm500q and exposes wwan0mbim0, wwan0at0 and an MBIM network device. A data session set up with mbimcli and with OpenWrt's umbim reached 160-180 Mbps, the limit of the cell. Assisted-by: LLM Signed-off-by: Steve Meek <stevemeek82@gmail.com> Link: https://patch.msgid.link/20261011-mhi-next-v1-1-13a738637ff0@gmail.com Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
2026-10-11Merge tag 'block-7.3-20261010' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull block fixes from Jens Axboe: - NVMe fixes via Keith: - Fix swapped ZRASF zone state values for full and read only - nvme-multipath revalidate head zones after unfreezing the head queue - Revert "nvme: do not reset controllers in NVME_CTRL_NEW state", which broke things - nvmet fixes for invalid NSIDs on feature 82h and using the local P2P device on metadata allocation failure - zloop: zero out only the unread tail of a short read * tag 'block-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: Revert "nvme: do not reset controllers in NVME_CTRL_NEW state" zloop: zero out only the unread tail of short reads nvmet: use the local P2P device on metadata allocation failure nvme-multipath: revalidate head zones after unfreezing the head queue nvme: fix swapped ZRASF zone state values for full and read only nvmet: return Invalid Field for invalid NSIDs feature 82h
2026-10-11landlock: Drop __counted_by from landlock_domain.handled_masksNguyen Ngoc Thang
With clang 22 and CONFIG_FORTIFY_SOURCE, the second landlock_restrict_self() call hits a bogus fortify report in inherit_ruleset(): memcpy: detected buffer overflow: 4 byte write of buffer size 0 Call Trace: __fortify_panic landlock_merge_ruleset __se_sys_landlock_restrict_self handled_masks[] lives in an anonymous struct inside the anonymous union that overlays work_free. For such a flexible array, clang computes the address of the __counted_by counter as the start of the array instead of &num_layers. The bound is then read from handled_masks[0], i.e. from the first layer's access masks, which is not a count. The same layout crashes clang itself in a standalone test. The annotation was added as documentation, so drop it rather than restructure the union. Keep the information in the member comment. Reported-by: syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a0eecb22de4d821a9e5d Fixes: bd3a19800dd1 ("landlock: Add counted_by in landlock_domain") Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com> Link: https://lore.kernel.org/r/20261010164450.194439-1-ngocthang2710.1999@gmail.com Reviewed-by: Günther Noack <gnoack3000@gmail.com> Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reported-by: Mike Bommarito <michael.bommarito@gmail.com> Closes: https://lore.kernel.org/r/20261009115108.17819-1-michael.bommarito@gmail.com [mic: Rebased on master, where the array is handled_masks[], updated the fortify report, added the clang bug link and the other reports] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-10-11Merge tag 'io_uring-7.3-20261010' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - Don't spin on local work the exiting task can't run. For a ring still R_DISABLED when the task got its tctx node, the submitter is set later and may be another task, so DEFER_TASKRUN local work stays pending forever and the exiting task spins in do_exit(). - Don't charge the SQ/CQ rings or provided buffer rings to RLIMIT_MEMLOCK. The region API conversion started charging them, which the rings had been exempt from. - Don't exempt disabled rings from task restrictions on register - Populate the CONNECT filter fields for a 24-byte sockaddr_in6 * tag 'io_uring-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring/cancel: don't spin on local work the task can't run io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6 io_uring/register: don't exempt disabled rings from task restrictions io_uring/kbuf: don't charge provided buffer rings to RLIMIT_MEMLOCK io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK
2026-10-11Merge tag 'xfs-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds
Pull xfs fixes from Carlos Maiolino: "This fixes a data corruption vector where a user could trick the exchange-range feature to add shared blocks beyond the file's EOF, which may then be used to modify data on another file" * tag 'xfs-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: fix exchange-range-to-eof file size exchange xfs: stop exchanging reflink flags when exchanging mappings
2026-10-11Merge tag 'x86-urgent-2026-10-11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Ingo Molnar: - Work around AMD TLBI Erratum #1718 (Borislav Petkov) * tag 'x86-urgent-2026-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU/AMD: Fix AMD TLBI Erratum #1718
2026-10-11Merge tag 'riscv-for-linus-7.3-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: "Several security fixes, a significant strnlen() regression fix, and several other miscellaneous fixes: - Fix a regression in the Zbb-enabled strnlen() implementation when huge counts are specified - When userspace pointer masking is enabled, strip the tag from user-specified pointers in two spots in the RISC-V futex code where this was missing - When CONFIG_SHADOW_CALL_STACK=y, use a supervisor mode-only CSR bit to determine whether the trap came from userspace or not, rather than a userspace-writable register - Reset the HSTATUS.HU bit during CPU initialization to avoid unexpected behavior, as the RISC-V specification does not require this bit to be hardware-reset - Fix the T-Head GhostWrite probing code when !CONFIG_ERRATA_THEAD_MAE - Fix RV32 boots using 32-bit.config by constraining NR_CPUS - Implement a workaround for SiFive MAL-9092, which requires fences around hypervisor load/store instructions - Fix the RISC-V patch_map() code to work properly for EXECMEM addresses when !CONFIG_STRICT_MODULE_RWX - Fix ptrace register set access reporting when CFI landing pad or shadow stack support is enabled - Avoid copying garbage into the target's vstate when PTRACE_SETREGSET is called with a short iov_len - Fix load_unaligned_zeropad() on RV32 kernels with CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y - Fix build breakage for any userspace program that includes uapi/asm/vendor/mips.h - Fix a build warning for 32-bit allmodconfig builds related to SiFive errata - Fix misspecified inline assembly constraints in the vector context save/restore code" * tag 'riscv-for-linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: fix load_unaligned_zeropad() fixup for RV32 riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp riscv: ptrace: Zero-initialize regset buffers before copyin riscv: ptrace: reject CFI regset access when extensions are absent riscv: fix NR_CPUS range leaking 64-bit default onto 32-bit builds riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE riscv: futex: untag the user pointer before the atomic access riscv: lib: Fix ZBB strnlen wrap-around regression on huge counts riscv: patch: fix handling of bpf-jit execmem addresses RISC-V: Clear HSTATUS.HU on CPU initialization RISC-V: errata: Add SiFive MAL-9092 workaround riscv: vector: Fix output operands in context save riscv: vector: Fix data pointer constraints in context save/restore riscv: limit sifive errata to CONFIG_64BIT riscv: hwprobe: use _BITULL() rather than BIT() in MIPS vendor uapi header
2026-10-11Merge tag 'input-for-v7.3-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: - A fix for the ati_remote2 sysfs attributes handling, resolving type confusion after conversion to dev_groups - Updates to the xpad joystick driver adding support for the Corsair Novablade Pro controller (wired and 2.4 GHz wireless) and a newer hardware revision of the 8BitDo Pro 2 Wired Controller for Xbox. * tag 'input-for-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox Input: xpad - add support for Corsair Novablade Pro Input: ati_remote2 - fix type confusion in device attribute handlers
2026-10-11usb: typec: ucsi_ccg: Add retry mechanism in ccg_readWayne Chang
CCG4 firmware occasionally fails to respond to I2C read requests, especially when reading cci and intr_reg from the ISR path. In these cases, i2c_transfer() returns -EREMOTEIO. The CCG4 is EOL, and Infineon no longer supports firmware updates, so a software workaround is necessary. Attempt the read up to CCG_READ_MAX_RETRIES (4) times in total when -EREMOTEIO is returned, sleeping ~1 ms via fsleep() between attempts. This allows recovery from transient I2C failures without affecting other error paths. The sleep is safe because ccg_read() is called both from process context and from ccg_irq_handler(), which runs in threaded IRQ context (registered via request_threaded_irq() with a NULL hard-IRQ handler), so sleeping is allowed in both cases. Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx") Cc: stable <stable@kernel.org> Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260916061858.1471606-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: host: xhci-tegra: Add Tegra264 XHCI supportWayne Chang
This change adds Tegra264 XUSB host mode controller support. The host controller is very similar to the existing Tegra234 XHCI, except the number of max_num_wakes. Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260903074539.613220-4-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: host: xhci-tegra: Skip MBOX MSG_ENABLED on Tegra264Wayne Chang
Tegra264 XUSB does not use the firmware mailbox handshake to enable controller messages (MBOX_CMD_MSG_ENABLED). Add a per-SoC flag and short-circuit __tegra_xusb_enable_firmware_messages() so both probe and resume avoid sending the command. Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260903074539.613220-3-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11dt-bindings: usb: Add Tegra264 XUSB host supportWayne Chang
Extend the Tegra234 XUSB host binding to cover Tegra264: - Add nvidia,tegra264-xusb compatible string - Document optional USB wake interrupts for Tegra264 - Document Tegra264 PMC wake event to port mapping - List the up to five IOMMU specifiers for the additional XUSB host stream IDs, since their order is now significant - Constrain interrupts and iommus counts for both Tegra234 and Tegra264 via allOf conditionals, since each SoC wires up a fixed number of wake interrupts and stream IDs Signed-off-by: Wayne Chang <waynec@nvidia.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260903074539.613220-2-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11Merge branch 'kbuild-bpf-support-inline-info-in-btf'Alexei Starovoitov
Alan Maguire says: ==================== kbuild, bpf: Support inline info in BTF If CONFIG_DEBUG_INFO_BTF_INLINE=y|m, add the "inline" BTF feature and encode inline site info in BTF alongside standard BTF data. resolve_btfids will then partition into non- and inline-related info and split BTF will be used to store inline info in a .BTF.inline section in vmlinux and modules. For CONFIG_DEBUG_INFO_BTF=m, vmlinux inline info will be stored in btf_vmlinux_inline.ko and will be loaded on-demand if used via /sys/kernel/btf/vmlinux.inline. A .BTF.inline.link section in vmlinux stores the module name, the SHA of the BTF and the size so that even without loading the kernel can size the sysfs representation correctly. This approach is based on [1] and the .BTF.inline.link section is modeled on .GNU_debuglink. Because a module can be built with .BTF.base to allow for BTF relocation, its inline info needs to be relocated also so a bit more work needs to be done to handle this. Patches 1, 2 add resolve_btfids support to partition BTF into .BTF and .BTF.inline and to support populating a BTF link section for BTF_INLINE=m. Patch 3 handles vmlinux.inline exposure in sysfs. Patch 4 does prep work for relocation needed in patch 5 prior to exposing relocated BTF in sysfs, and patches 6 and 7 test BTF sysfs representations and inline validity using bpf_testmod respectively. To generate inline info the latest pahole is needed [2]. Inline info for vmlinux can be quite large ~10Mb for over 600,000 inline sites in the kernel, so CONFIG_DEBUG_INFO_BTF_INLINE=m is recommended; this brings the on-disk size down below 4Mb for a gzip-compressed btf_vmlinux_inline.ko. Changes since v3 [3]: - Retain original BTF in resolve_btfids and be careful about free order (bots, patch 1) - Add more failure diagnostics to patching of BTF links (bots, patch 2) - Guard vmallocs for zero-sized inline data (bots, patch 3) - Fix potential NULL pointer BTF deref (bots, patch 5) - Fix up leaks in sysfs test (bots, patch 6) - Fix up tests to use kallsyms lookup directly, and improve validation of location info (bots, patch 7) Changes since v2 [4] - Delivered the libbpf, bpftool parts are prerequisites - Switched to using Eduard's neater BTF partitioning approach which is fully in resolve_btfids instead of libbpf (Eduard, patch 1) - Supports mmap()ed vmlinux.inline (Alexei, patch 3, test patch 7) - Moved to using .BTF.inline.link to store inline BTF size which avoids need to switch to using kernfs; also allows us to SHA-verify BTF inline info [1] https://lore.kernel.org/bpf/20260925224229.1850-1-wanjay@amazon.com/ [2] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ [3] https://lore.kernel.org/bpf/20261003194323.817885-1-alan.maguire@oracle.com/ [4] https://lore.kernel.org/bpf/20260901165757.801449-1-alan.maguire@oracle.com/ ==================== Link: https://patch.msgid.link/20261009112324.1442319-1-alan.maguire@oracle.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-10-11selftests/bpf: Add a test verifying inline informationAlan Maguire
For bpf_testmod verify that we have inline info for an __always_inline'd function and it matches reasonable expectations (a single location parameter encoded in a register given that it cannot be compile-time optimized). Also verify that the offset of the LOCSEC descriptor makes sense, i.e. that it is in the range of the function where it was inlined. Because bpf_testmod is treated as an out-of-tree module, the inline information will be in btf_testmod.inline which is relocated using bpf_testmod.ko .BTF.base. Test is skipped if pahole does not encode inline info. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-8-alan.maguire@oracle.com
2026-10-11selftests/bpf: Test BTF sysfs inline representationsAlan Maguire
Load vmlinux, vmlinux.inline and all module and module.inline entries in /sys/fs/btf; this will allow us to sanity-check - kernel and its inline representations - in-tree modules and their inline multi-split BTF representations - out-of-tree modules and the kernel relocation done for module and module inline BTF Since bpf_testmod.ko is built as an out-of-tree module, the combination of vmlinux, normal in-tree module BTF and out-of-tree testmod ensures we sanity check relocations for each case. Also test mmap for vmlinux.inline. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-7-alan.maguire@oracle.com
2026-10-11btf: Relocate and expose module inline BTFAlan Maguire
Module .BTF.inline is split relative to its module BTF. For external modules, module BTF can instead be split relative to a distilled .BTF.base and is relocated against vmlinux when the module loads. Parse ordinary module inline BTF relative to the pre-relocation module BTF. Retain the module relocation ID and string maps, then rebase inline type IDs and string offsets onto the final vmlinux/module BTF space before exposing the result through sysfs. Malformed or unrelocatable optional inline BTF is warned about and omitted without preventing normal module BTF registration. The btf_vmlinux_inline carrier remains on its existing hash-checked, vmalloc-backed publishing path, preserving mmap support for vmlinux.inline when delivered by a module. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-6-alan.maguire@oracle.com
2026-10-11btf: Preserve string relocation maps for split BTFAlan Maguire
Make btf_relocate() optionally return the string-offset map it builds while relocating a BTF relative to a distilled base. A subsequent split BTF object can use that map to rebase references to base strings. Also account for the accumulated base string offset when assigning a new BTF base. This is required when the base is itself split. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-5-alan.maguire@oracle.com
2026-10-11kbuild, btf: Expose vmlinux inline BTF through sysfsAlan Maguire
Expose BTF inline-location information from vmlinux .BTF.inline sections in /sys/kernel/btf as vmlinux.inline. Embedded vmlinux inline BTF supports read-only mmap(). Provide runtime support for a module-delivered vmlinux inline BTF carrier. Its link record binds the carrier module name, BTF size, and SHA-256 digest to the running kernel before its data is made available through a lazy vmlinux.inline sysfs attribute. The carrier is handled before ordinary module BTF registration, so its incidental .BTF data is not exposed. Make CONFIG_DEBUG_INFO_BTF_INLINE tristate. When configured as a module, retain vmlinux final split inline BTF for btf_vmlinux_inline.ko instead of embedding it in vmlinux. Reserve .BTF.inline.link in vmlinux and extend the final resolve_btfids patch pass to bind btf_vmlinux_inline to the raw vmlinux.BTF.inline payload. This preserves the normal built-in configuration while allowing the large inline BTF payload to load on demand. Normal module inline BTF is handled separately, after its references have been relocated against the final module BTF. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-4-alan.maguire@oracle.com
2026-10-11resolve_btfids: Populate BTF link sectionAlan Maguire
Allow the final BTF patch pass to populate one or more BTF link records. A link identifies the BTF section to be delivered, its carrier module, and the raw finalized BTF payload: --btf_link <section>:<module>:<raw-btf-file> Use the raw file size and SHA-256 digest to populate the corresponding <section>.link record. This avoids reparsing BTF during final ELF patching and supports inline vmlinux BTF linking. Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-3-alan.maguire@oracle.com
2026-10-11resolve_btfids: Build separate main and inline BTF objectsEduard Zingerman
Extract .BTF.inline via the following logic: - Traverse all types reachable from LOC_PARAM, LOC_PROTO, LOCSEC entries and mark them as having LOC color. - Traverse all types reachable from the remaining types and mark them as having MAIN or SHARED. - Create a new base BTF object and copy all MAIN/SHARED types there. - Create a new .BTF.inline object with base set to the new base BTF object, and copy all LOC types there. This way .BTF.inline can refer to types and strings in the new base, and strings used only by .BTF.inline remain in it. Additionally, all BTF_KIND_FUNC types that map to ELF symbols with the same name are forced to be in the base BTF. Same for types referenced from BTF id sets. Regular types referenced only from .BTF.inline remain in the base BTF, and sizes are 5 and 9.5Mb for vmlinux and vmlinux.inline respectively. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261009112324.1442319-2-alan.maguire@oracle.com
2026-10-11usb: xhci-pci: Add TUSB73x0 definitionsFabio Estevam
Instead of hard-coding the TUSB73X0 PCI ID, USB_CTRL register address and the PWRON_POLARITY, introduce definitions for them to make the code easier to read. No functional change. Signed-off-by: Fabio Estevam <festevam@gmail.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Link: https://patch.msgid.link/20261009125154.266435-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11dt-bindings: usb: generic-xhci: add Axiado AX3005 xHCI variantSwark Yang
The Axiado AX3005 xHCI controller is software-compatible with the generic xHCI programming interface and uses "generic-xhci" as its fallback, as do the Marvell Armada 37xx/8k controllers. Add "axiado,ax3005-xhci" to the existing compatible enum instead of adding a separate schema entry. Since the enum no longer covers only Armada parts, drop the "Armada 37xx/8k SoCs" description rather than leave it inaccurate. Signed-off-by: Swark Yang <syang@axiado.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260805-upstrea-ax3005-usb-v4-v4-1-796af97bfce4@axiado.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci-pci: Add AMD 600 series to xhci-pci-prom21Stephen Horvath
It seems the xhci-pci-prom21 module only has IDs for the 800 series chipsets. However, the 600 series chipsets also have Promontory 21 chips, so we should add their IDs to the list as well. I have tested this on my X670 board featuring DID `0x43f7`. `1022:43f7` also appears on the PCI ID database (https://pci-ids.ucw.cz/read/PC/1022/43f7). Device IDs `0x43f9` (B665) & `0x43fa` (A620) were suggested by Shyam. Also list the new IDs in Documentation/hwmon/prom21-xhci.rst. Cc: stable@vger.kernel.org # 7.2.x Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Cc: Jihong Min <hurryman2212@gmail.com> Signed-off-by: Stephen Horvath <linux@stevetech.au> Tested-by: Mirko Jechow <mirko.jechow@gmx.de> [mirko.jechow@gmx.de: add new IDs to prom21-xhci.rst] Signed-off-by: Mirko Jechow <mirko.jechow@gmx.de> Link: https://patch.msgid.link/20261004002731.49927-1-mirko.jechow@gmx.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11xhci: Prevent invalid vdev dereference during sideband unregisterMathias Nyman
Offloaded USB audio devices using the xhci-sideband API store a pointer to the xhci virtual device (vdev) in the sideband structure when registering. This pointer typically remains valid throughout the lifetime of the USB device. If a configured offloaded device requires a reset, the USB core usually unbinds or notifies the audio driver beforehand, ensuring that the sideband is unregistered before the vdev is freed. An exception occurs when the USB core resets a device to recover from a failed resume, but a subsequent 'address device' request also fails. To recover in this specific scenario, the xHCI driver disables and re-enables the slot, which frees and re-allocates the vdev. xhci_sideband_unregister() later dereferences the stale, previously freed vdev pointer during disconnect, triggering a kernel oops: Unable to handle kernel paging request at virtual address dead000000000122 Call trace: xhci_get_ep_ctx+0x0/0x38 xhci_sideband_unregister+0x68/0xf0 uaudio_disconnect+0x70/0x144 usb_audio_disconnect+0x7c/0x268 usb_unbind_interface+0x13c/0x340 device_release_driver_internal+0x1c4/0x2bc usb_disable_device+0x84/0x190 usb_disconnect+0xe8/0x338 hub_event+0xbd8/0x19ac Fix this by preventing the reallocation of the vdev in this specific error path if the device is registered for sideband use. Just propagate the error directly to the USB core. It should either retry enumeration or detect the disconnected device, and handle it accordingly. Debugging this issue to the dangling vdev pointer, reporting it, testing, and initial patch with different solution by Lianqin Hu Reported-by: Lianqin Hu <hulianqin@vivo.com> Closes: https://lore.kernel.org/linux-usb/TYUPR06MB6217000B59003EDF233D7246D2B22@TYUPR06MB6217.apcprd06.prod.outlook.com/ Tested-by: Lianqin Hu <hulianqin@vivo.com> Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-12-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: Fix bounce buffer overflowMichal Pecio
High-speed devices with out of spec 1024 byte bulk endpoints exist and are allowed by USB core, but xhci-hcd always sets packet size to 512. The exact nature of these devices isn't documented, commit fb5ee84ea72c ("USB: Accept bulk endpoints with 1024-byte maxpacket") only states that they "don't work with xHCI host controllers", whatever it means. But somebody (or a malicious device) can try, and then the driver will allocate a 512 byte bounce buffer for this endpoint and may write up to 1024 bytes into it if particular scatter-gather URBs are used, because xhci_align_td() obtains packet size from the descriptor. Fix this. As a side effect, TRBs will be aligned to the packet size chosen by the driver on all endpoints of all speeds. Alignment serves the xHC, not device, so this is fine. Only out of spec devices are affected anyway. Reported-by: co+fd80bc5967eb22c3@bugs.sh Link: https://lore.kernel.org/linux-usb/D4tcSGerkYkIV1DmaUo1t8TaR5qQElDLkidn@bugs.sh/ Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: Rework and improve the TD matching and skipping logicMichal Pecio
Matching events with TDs and giving back missed TDs is carried out by a complicated loop. Replace it with a simpler linear logic: 0. Having verified that 'td_list' isn't empty, 1. Scan it to find the matching TD and count missed TDs, 2. Perform necessary adjustments for corner cases, 3. Give back missed TDs, if applicable, using a short and tidy loop, 4. Check if the event refers to the expected TD and proceed as usual. Besides cleaning up the code, this provides a few improvements: - when the skip flag is set, no TD is given back unless we found a match or otherwise know how many TDs should be given back - when the skip flag is clear, we know if the event refers to a "future" TD so we can log this in the Scary Error Message to aid debugging. While altering the error message, drop a pointless goto. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-10-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: Shorten the TD skipping loopMichal Pecio
Half of this loop is code which only executes once to deal with cases where no TD matches the event and then it returns. This code needs not to be in any kind of loop, so get it out. Optimize conditionals remaining in the loop body. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: Don't set the skip flag on non-isoc endpointsMichal Pecio
These events are unique to isochronous endpoints, ignore them otherwise. Update debug messages to reflect new policies. We could also log invalid events as errors, but it seems nobody has ever had problems with that, so don't bother. This allows dropping the isoc check when skipping TDs. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-8-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: Guarantee URB giveback on Ring Underrun/OverrunMichal Pecio
In this case we know that the xHC has released ownership of all missed TDs, we only don't know which were missed and which were queued later. URBs are queued atomically, so we can safely give back all TDs of the currently executing URB. Unlike the previous policy, this does actually ensure that the class driver will learn about the error and won't see all of its URBs still in progress when all TDs are missed on xHCI 1.0. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11xhci: dbc: lock the minor IDR on registration failureSang-Hoon Choi
dbc_tty_minors is protected by dbc_tty_minors_lock when entries are allocated and during normal device removal. The registration error path removes an entry without taking that lock. Different DbC instances have separate event work items, so this removal can race with an IDR update for another instance. Take the same mutex around the error-path removal. Fixes: e1ec140f273e ("xhci: dbgtty: use IDR to support several dbc instances.") Reported-by: Changyul Lee <lcy8047@gmail.com> Assisted-by: LLM Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11xhci: check device notification type before forwarding wake eventHongyu Xie
The xHCI driver programs the Device Notification Control register to only enable the Function Wake device notification (N1), so any Device Notification Event TRB received is expected to be a function wake notification. handle_device_notification() does however not check the Notification Type field of the event (xHCI 1.2 section 6.4.2.7, DW0 bits 7:4), and forwards every device notification event as a function wake. A host controller that delivers an unexpected notification type (e.g. due to broken firmware or emulation) would trigger a spurious wake notification on the parent hub. Parse the notification type and drop events other than Function Wake with a warning, mirroring the slot ID validation in the same function. DEV_NOTE_FWAKE is the DNCTRL register bit for notification type 1 (N1), while the event TRB carries the notification type value itself, so add a separate DEV_NOTE_TYPE_FWAKE constant for the comparison. [mn:] reduce warning to a debug message Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: fix typos in commentsZain Aboobacker
Fix various spelling mistakes in comments found by codespell. Assisted-by: Claude:claude-opus-5-5 codespell Signed-off-by: Zain Aboobacker <zainaboobacker33@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: Unlock for command abort pollingMichal Pecio
xhci_abort_cmd_ring() requests abort, waits for the CRR bit to clear, drops xhci->lock and waits for the Command Ring Stopped event. The CRR wait timeout is 5 seconds as suggested by xHCI 4.6.1.2, which means that if the xHC fails to complete the operation at all, we poll with the lock held and IRQs disabled for several seconds. If any other CPU tries to acquire the lock, it will spin likewise. IRQs get delays, drivers log errors, tasks freeze, it's a mess. So drop the lock earlier, before waiting for the CRR bit. It should be safe - the sole caller sets cmd_ring_state to CMD_RING_STATE_ABORTED before calling us, which will prevent others from ringing the command doorbell and interfering with the abort. Queuing new commands during this time poses no danger, and if the command we try to abort actually completes concurrently, existing code already needs to deal with this. And in my testing it does - it's trivial to trigger this on ASM1042, where Address Device can't be aborted, but it completes as soon as the offending device is unplugged, including during abort attempt. Note that the lock still covers reinit_completion(), so it won't race with complete() being called by the event handler. And works are not reentrant, so another timeout can't expire while the lock is dropped. We will configure timeout anew when restarting the ring. One other difference is that now we also drop the lock if abort fails. This too should be harmless. Commands queued during this time will be released like any other pending commands. If the aborted command does complete before we regain the lock, it's a waste, but not regression. Reported-by: Pedro Fonseca <pedro@fonseca.com.pt> Link: https://lore.kernel.org/linux-usb/16f65081-5a3c-4c30-9811-9017796a3373@fonseca.com.pt/ Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: xhci: return an error if the host is not haltedHenry Tseng
xhci_reset() returns 0 when the host is not halted, without ever writing CMD_RESET. Every other path that fails to reset the host returns an error, so callers that check the return value are told the reset succeeded on the one path where it did not happen. Return -EBUSY when the reset is aborted because the host is not halted. Signed-off-by: Henry Tseng <henrytseng@qnap.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20261009151624.618967-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-10-11usb: typec: ucsi: ccg: Validate altmode index in GET_CURRENT_CAM responseSeungjin Bae
When the PPM reports more than one DisplayPort alternate mode for a connector, ucsi_ccg_update_altmodes() merges them into a single entry in uc->updated[] and sets uc->has_multiple_dp. In that case, ucsi_ccg_update_get_current_cam_cmd() rewrites the response of the GET_CURRENT_CAM command. The response is a single byte holding the index of the currently active alternate mode, and it is provided by the PPM firmware. The function uses this byte directly as an index into uc->orig[], and then uses the linked_idx read from that entry as the translated index into uc->updated[]. Both arrays have UCSI_MAX_ALTMODES entries, but neither index is checked against that size. If a malicious or buggy PPM reports a value of UCSI_MAX_ALTMODES or larger, e.g. 0xFF, uc->orig[cam].linked_idx reads over the end of uc->orig[]. The byte read from there is then used as the index for writing cam into uc->updated[new_cam].active_idx, so the out-of-bounds read is followed by an out-of-bounds write. This happens without any userspace action, since the UCSI core issues GET_CURRENT_CAM on its own when handling connector changes. Fix this by rejecting responses whose index is out of range, printing an error and returning -EPROTO, so that the caller cannot accept this. Also check linked_idx before using it as an index, so that the write into uc->updated[] is always within bounds. The response is now only processed when the command completed without an error. ucsi_sync_control_common() only reads the response when the CCI reports command completion, so otherwise the buffer is not filled and must not be mistaken for an invalid index. This bug was found with a Python script that traces where firmware input is used. Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices") Cc: stable <stable@kernel.org> Reported-by: Nathan Rebello <nathan.c.rebello.27@dartmouth.edu> Assisted-by: LLM Signed-off-by: Seungjin Bae <eeodqql09@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20261003215520.611083-2-eeodqql09@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>