Re: [PATCH v2] usb: xhci: print xhci->xhc_state when queue_command failed

[Su Hui <suhui@nfschina.com>]

On 2025/7/25 18:03, Michał Pecio wrote:
> Hi,
>
> On Fri, 25 Jul 2025 14:01:18 +0800, Su Hui wrote:
>> When encounters some errors like these:
>> xhci_hcd 0000:4a:00.2: xHCI dying or halted, can't queue_command
>> xhci_hcd 0000:4a:00.2: FIXME: allocate a command ring segment
>> usb usb5-port6: couldn't allocate usb_device
>>
>> It's hard to know whether xhc_state is dying or halted.
> Is it truly a problem? This is the only place which sets
> XHCI_STATE_DYING that I found in the whole drivers/ tree:
>
>          xhci_err(xhci, "xHCI host controller not responding, assume dead\n");
>          xhci->xhc_state |= XHCI_STATE_DYING;
>
> And AFAIK such state can only be exited by unbinding the driver.
> Are there really cases when it's unclear if the HC is dying or not?
Oh, my fault, I ignored this so obvious error message. :(.
Sorry for the noise, Maybe this patch should be removed.
>
>> So it's better to print xhc_state's value which can help locate the
>> resaon of the bug.
>>
>> Hmm, any chance you came across bugs that upstream should know about?
Actually, this bug is specific to the 5.4 version of the kernel and a 
particular USB camera. I am working
to resolve this issue. When the xhci_hcd is initialized, the driver sets 
xhc_state to "halted", but before
the xhci_hcd calls xhci_start, the hub starts Initializing. Hub 
initialization failed due to xhc_state being
halted. Perhaps this issue is caused by hardware...

Su Hui