On 27.8.2024 16.29, Łukasz Bartosik wrote:
On 8/22/24 15:02, Mathias Nyman wrote:
Don't flush all pending DbC data requests when an endpoint halts.
An endpoint may halt and xHC DbC trigger a STALL error event if there's an
trigger -> triggers
issue with a bulk data transfer. The transfer should restart once xHC DbC
receives a ClearFeature(ENDPOINT_HALT) request from the host.
Once xHC DbC restarts it will start from the TRB pointed to by dequeue
field in the endpoint context, which might be the same TRB we got the
STALL event for. Turn the TRB to a no-op in this case to make sure xHC
DbC doesn't reuse and tries to retransmit this same TRB after we already
handled it, and gave its corresponding data request back.
Other STALL events might be completely bogus.
Lukasz Bartosik discovered that xHC DbC might issue spurious STALL events
if hosts sends a ClearFeature(ENDPOINT_HALT) request to non-halted
endpoints even without any active bulk tranfers.
tranfers - > transfers
Assume STALL event is spurious if it reports 0 bytes tranferred, and
tranferred -> transferred
the endpoint stopped on the STALLED TRB.
Don't give back the data request corresponding to the TRB in this case.
The halted status is per endpoint. Track it with a per endpoint flag
instead of the driver invented DbC wide DS_STALLED state.
DbC remains in DbC-Configured state even if endpoints halt. There is no
Stalled state in the DbC Port state Machine (xhci section 7.6.6)
Reported-by: Łukasz Bartosik <ukaszb@xxxxxxxxxxxx>
Closes: https://lore.kernel.org/linux-usb/20240725074857.623299-1-ukaszb@xxxxxxxxxxxx/
Signed-off-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
---
Tested-by: Łukasz Bartosik <ukaszb@xxxxxxxxxxxx>
In the trace below stall errors happen and even though the short
packet is processed
instead of being dropped as it happened previously without this fix.
Thanks, fixed typos and added patch to queue
-Mathias
