Re: [PATCH] xhci: sideband: check vdev liveness before removing endpoints on unregister

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 9/14/26 12:09, Michal Pecio wrote:
> On Mon, 14 Sep 2026 07:04:17 +0000, 胡连勤 wrote:
>>> It doesn't cover hub_port_reset() called by port_event() for
>>> SuperSpeed devices, not sure what that is and whether it's
>>> dangerous. I noted that the original patch talks about hub_event(),
>>> but maybe it's a mistake?
>>
>> Thanks for the analysis. A clarification on the hub_event() reference
>> in my patch:
>>
>> The crash trace shows hub_event() at the top because that's the actual
>> crash call stack from the failing device. The full sequence is:
>>
>>    hub_event()
>>      -> port_event()                           [hub.c:5966]
>>         -> usb_reset_device(udev)              [hub.c:5875]
>>            -> usb_reset_and_verify_device()    [hub.c:6183]
>>               -> hub_port_init()               [hub.c:6228]
>>                  -> hcd->driver->address_device()  [hub.c:4781]
>>                     -> xhci_setup_device()     <-- COMP_USB_TRANSACTION_ERROR
>>                        -> xhci_disable_and_free_slot()  [xhci.c:4438]
>>                           -> xhci_free_virt_device()   <-- frees vdev here
> 
> So not a mistake and this is indeed a dangerous case. And AFAICT, in
> this path udev's pre_reset() routine isn't called and therefore can't
> be used to fix your issue, unless USB core is patched to call it.
> 
> But xhci_discover_or_reset_device() is called: before hub_port_init()
> calls problematic hub_enable_device() / hub_address_device() functions,
> it calls hub_port_reset(), which calls hcd->driver->reset_device().

To me it looks like both drv->pre_reset and xhci_discover_or_reset_device()
are called in this path.

hub_event()
   port_event()
     usb_reset_device(udev)
       if (config) //and for each interface in this config: , for each interface)
         if (cintf->dev.driver) {
           drv = to_usb_driver(cintf->dev.driver);
           if (drv->pre_reset && drv->post_reset)
           unbind = (drv->pre_reset)(cintf);


Any chance you could trace the whole call path in more details and see exactly which path
is staken before the crash.

port_event() should only call usb_reset_device() for usb3 devices with link stuck in
ss.inactive for longer than ~100ms.  Is this really a usb3 audio device?

Thanks
Mathias