Comment 252 for bug 1667750

Revision history for this message
In , mathias.nyman (mathias.nyman-linux-kernel-bugs) wrote :

Seems that it was a known issue that xHCI on AMD platforms can fail to restart an endpoint if it wasn't running when the stop command was issued. This also applies to Berhards case where the endpoint stop command raced with an error halting the endpoint.
See patch:

commit 28a2369f7d72ece55089f33e7d7b9c1223673cc3
Author: Shyam Sundar S K <email address hidden>
Date: Thu Jul 20 14:48:28 2017 +0300

    usb: xhci: Issue stop EP command only when the EP state is running

    on AMD platforms with SNPS 3.1 USB controller if stop endpoint command is
    issued the controller does not respond, when the EP is not in running
    state. HW completes the command execution and reports
    "Context State Error" completion code. This is as per the spec. However
    HW on receiving the second command additionally marks EP to Flow control
    state in HW which is RTL bug. This bug causes the HW not to respond
    to any further doorbells that are rung by the driver. This makes the EP
    to not functional anymore and causes gross functional failures.

    As a workaround, not to hit this problem, it's better to check the EP state
    and issue a stop EP command only when the EP is in running state.

    As a sidenote, even with this patch there is still a possibility of
    triggering the RTL bug if the context state races with the stop endpoint
    command as described in xHCI spec 4.6.9

    [code simplification and reworded sidenote in commit message -Mathias]
    Signed-off-by: Shyam Sundar S K <email address hidden>
    Signed-off-by: Nehal Shah <email address hidden>
    Signed-off-by: Mathias Nyman <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

Does anybody have a link to that errata?