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

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 14 Sep 2026 13:00:40 +0000, 胡连勤 wrote:
> > > 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.

Regards,
Michal