summaryrefslogtreecommitdiff
path: root/scripts/extract-fwblobs
diff options
context:
space:
mode:
authorMarc Zyngier <maz@kernel.org>2025-02-27 22:45:29 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-03-03 12:10:06 +0300
commit487cfd4a8e3dc42d34a759017978a4edaf85fce0 (patch)
tree1270719ada3ae847232f4d494b685d61b57b4eef /scripts/extract-fwblobs
parentc133ec0e5717868c9967fa3df92a55e537b1aead (diff)
downloadlinux-487cfd4a8e3dc42d34a759017978a4edaf85fce0.tar.xz
xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts
When adding support for USB3-over-USB4 tunnelling detection, a check for an Intel-specific capability was added. This capability, which goes by ID 206, is used without any check that we are actually dealing with an Intel host. As it turns out, the Cadence XHCI controller *also* exposes an extended capability numbered 206 (for unknown purposes), but of course doesn't have the Intel-specific registers that the tunnelling code is trying to access. Fun follows. The core of the problems is that the tunnelling code blindly uses vendor-specific capabilities without any check (the Intel-provided documentation I have at hand indicates that 192-255 are indeed vendor-specific). Restrict the detection code to Intel HW for real, preventing any further explosion on my (non-Intel) HW. Cc: stable <stable@kernel.org> Fixes: 948ce83fbb7df ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts") Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250227194529.2288718-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'scripts/extract-fwblobs')
0 files changed, 0 insertions, 0 deletions