summaryrefslogtreecommitdiff
path: root/tools/lib/python
diff options
context:
space:
mode:
authorMichal Pecio <michal.pecio@gmail.com>2025-11-19 17:24:04 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-11-21 16:53:00 +0300
commite6aec6d9f5794e85d2312497a5d81296d885090e (patch)
tree0cbafb9e8700cbeab75c9891451eb519b58b0e1b /tools/lib/python
parentf7812977456c3c1efc69ecf79ea88302bf472f4b (diff)
downloadlinux-e6aec6d9f5794e85d2312497a5d81296d885090e.tar.xz
usb: xhci: Don't unchain link TRBs on quirky HCs
Some old HCs ignore transfer ring link TRBs whose chain bit is unset. This breaks endpoint operation and sometimes makes it execute other ring's TDs, which may corrupt their buffers or cause unwanted device action. We avoid this by chaining all link TRBs on affected rings. Fix an omission which allows them to be unchained by cancelling TDs. The patch was tested by reproducing this condition on an isochronous endpoint (non-power-of-two TDs are sometimes split not to cross 64K) and printing link TRBs in trb_to_noop() on good and buggy HCs. Actual hardware malfunction is rare since it requires Missed Service Error shortly before the unchained link TRB, at least on NEC and AMD. I have never seen it after commit bb0ba4cb1065 ("usb: xhci: Apply the link chain quirk on NEC isoc endpoints"), but it's Russian roulette and I can't test all affected hosts and workloads. Fairly often MSEs happen after cancellation because the endpoint was stopped. Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://patch.msgid.link/20251119142417.2820519-11-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions