On 20.12.2022 9.58, Ladislav Michl wrote:
On Mon, Dec 19, 2022 at 10:45:43PM +0100, Ladislav Michl wrote:
On Mon, Dec 19, 2022 at 07:31:02PM +0100, Ladislav Michl wrote:
On Mon, Dec 19, 2022 at 02:25:46PM +0200, Mathias Nyman wrote:
Looks like controller didn't complete the stop endpoint command.
Event for last completed command (before cycle bit change "c" -> "C") was:
0x00000000028f55a0: TRB 00000000035e81a0 status 'Success' len 0 slot 1 ep 0 type 'Command Completion Event' flags e:c,
This was for command at 35e81a0, which in the command ring was:
0x00000000035e81a0: Reset Endpoint Command: ctx 0000000000000000 slot 1 ep 3 flags T:c
The stop endpoint command was the next command queued, at 35e81b0:
0x00000000035e81b0: Stop Ring Command: slot 1 sp 0 ep 3 flags c
There were a lot of URBs queued for this device, and they are cancelled one by one after disconnect.
Was this the only device connected? If so does connecting another usb device to another root port help?
Just to test if the host for some reason partially stops a while after last device disconnect?
Device is connected directly into SoC. Once connected into HUB, host doesn't die
(as noted in other email, sorry for not replying to my own message, so it got lost)
It seems as intentional (power management?) optimization. If another device is
plugged in before 5 sec timeout expires, host completes stop endpoint command.
Unfortunately I cannot find anything describing this behavior in
documentation, so I'll ask manufacturer support.
As support is usually slow I asked search engine first and this sounds
familiar:
"Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to prevent
xhci host controller from dying when device is disconnected."
usb: dwc3: Add quirk for Synopsis device disconnection errata
https://patchwork.kernel.org/project/linux-omap/patch/1424151697-2084-5-git-send-email-Sneeker.Yeh@xxxxxxxxxxxxxx/
Any clue what happened with that? I haven't found any meaningfull traces...
Just for completeness, this turned into:
41135de1e7fd ("usb: xhci: add quirk flag for broken PED bits")
and it is enabled:
cc params 0x0220f065 hci version 0x100 quirks 0x0000000002010010
However I do not see original logic there, clearing PORT_CSC before
stopping endpoint.
CSC is cleared to allow xHC future port change events reporting.
we don't want to miss when something is re-connected.
Hardware shouldn't stop running based on cleared CSC, it should stop when
driver clears the USBCMD register Run/Stop bit.
-Mathias
