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

[胡连勤]

Hi Michal,

> > > > 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.
> 
> Yes, you are right. I mistakenly looked at the "warm reset, port only"
> case but there seems to be no possibility of falling into this path.
> 
> BTW, SuperSpeed audio devices do exist. Basically, any audio function
> in a larger device which needs the bandwidth. Similar thing with HID.
> 
> > 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.
> 
> Note that xhci_setup_device() is involved, which is called from
> hub_enable_device() and hub_set_address(), and these are called
> from hub_port_init(), which is used by hub_port_connect() and
> usb_reset_and_verify_device(). So something happens there.
> 
> Is this reproducible? Then add to xhci_free_virt_device():
> 
> 	if (dev->sideband)
> 		dump_stack()
> 
> and we will know how it happens.

Unfortunately, no. The reproduction rate is very low, and we have
not yet found a stable way to reproduce it — it requires the
device to be in a specific state where the port is disabled after
autosuspend resume, which happens rarely in the field.

Regards,
Lianqin