summaryrefslogtreecommitdiff
path: root/rust/helpers/security.c
diff options
context:
space:
mode:
authorMichal Pecio <michal.pecio@gmail.com>2025-09-18 00:07:20 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-09-18 09:53:11 +0200
commit08fa726e66039dfa80226dfa112931f60ad4c898 (patch)
treeb5bc05ce9907e409f744c079b2eaef93f3da1713 /rust/helpers/security.c
parent41f71deda1c12e063a0793252021f37e790d1ef1 (diff)
Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running"
This reverts commit 28a76fcc4c85dd39633fb96edb643c91820133e3. No actual HW bugs are known where Endpoint Context shows Running state but Stop Endpoint fails repeatedly with Context State Error and leaves the endpoint state unchanged. Stop Endpoint retries on Running EPs have been performed since early 2021 with no such issues reported so far. Trying to handle this hypothetical case brings a more realistic danger: if Stop Endpoint fails on an endpoint which hasn't yet started after a doorbell ring and enough latency occurs before this completion event is handled, the driver may time out and begin removing cancelled TDs from a running endpoint, even though one more retry would stop it reliably. Such high latency is rare but not impossible, and removing TDs from a running endpoint can cause more damage than not giving back a cancelled URB (which wasn't happening anyway). So err on the side of caution and revert to the old policy of always retrying if the EP appears running. [Remove stable tag as we are dealing with theoretical cases -Mathias] Fixes: 28a76fcc4c85d ("usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running") Signed-off-by: Michal Pecio <michal.pecio@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20250917210726.97100-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'rust/helpers/security.c')
0 files changed, 0 insertions, 0 deletions