diff options
| author | Michal Pecio <michal.pecio@gmail.com> | 2025-11-19 17:24:04 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-11-21 16:53:00 +0300 |
| commit | e6aec6d9f5794e85d2312497a5d81296d885090e (patch) | |
| tree | 0cbafb9e8700cbeab75c9891451eb519b58b0e1b /tools/lib/python | |
| parent | f7812977456c3c1efc69ecf79ea88302bf472f4b (diff) | |
| download | linux-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
