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

[Mathias Nyman]

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