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

[Mathias Nyman]

On 9/14/26 16:00, 胡连勤 wrote:
> Hi Mathias,
>
> > > 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.
> Your code tracing is correct. drv->pre_reset() IS called at
> hub.c:6412 before usb_reset_and_verify_device(), and
> xhci_discover_or_reset_device() IS called via hub_port_reset() →
> hcd->driver->reset_device() inside hub_port_init().
>
> However, this path is not the actual crash path. I apologize —
> my earlier call chain referencing usb_reset_device() was an
> assumption, not from the actual crash dump.
>
>
> > 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?
> No, it is not. The device is a full-speed Apple EarPods
> (USB 1.1):
>
>    usb 1-1: new full-speed USB device number 2 using xhci-hcd
>    usb 1-1: Product: EarPods
>    usb 1-1: New USB device found, idVendor=05ac, idProduct=110b
>
> So the port_event() → usb_reset_device() warm-reset path for
> SS.Inactive does not apply here.
> The actual crash path is through usb_disconnect(), not
> usb_reset_device(). The full sequence from dmesg + crash trace:

Thanks for clarifying, the crash part is now clear.

What is still unclear is the parts before this.
How do we end up in a situation where we are resetting and addressing
a device with sideband still registered.

What codepath ends up calling the futile

hub_port_init()
  ->hub_address_device()

that ends up freeing and reallocating the xhci vdev?

Is there a way (like drv->pre_reset call) among that path to
inform audio driver to unregister sideband?

Thanks
Mathias