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

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

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