Re: [RFC PATCH] usb: xhci: Skip configure EP for disabled slots during teardown

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

Hi

On 1/5/26 10:48, Udipto Goswami wrote:
> Consider a scenario when a HS headset fails resume and the hub performs
> a logical disconnect, the USB core tears down endpoints and calls
> hcd->check_bandwidth() on the way out, which with xHCI translates to a
> drop-only Configure Endpoint command (add_flags == SLOT_FLAG, drop_flags
> != 0). If the slot is already disabled (slot_id == 0) or the virtual
> device has been freed, issuing this Configure Endpoint command is
> pointless and may appear stuck until event handling catches up,
> causing unnecessary delays during disconnect teardown.
> 
> Fix this by adding a check in xhci_check_bandwidth(), return success
> immediately if slot_id == 0 or vdev is missing, preventing the
> Configure Endpoint command from being queued at all. Additionally,
> in xhci_configure_endpoint() for drop-only Configure Endpoint operations,
> return success early if slot_id == 0 or vdev is already freed,
> avoiding spurious command waits.
> 
> Signed-off-by: Udipto Goswami <udipto.goswami@oss.qualcomm.com>

Makes sense to prevent unnecessary 'configure endpoint' commands

Could you share more details how we end up tearing down endpoints and
calling xhci_check_bandwidth() after vdev is freed and slot_id set to zero?

Did the whole xHC controller fail to resume and was reinitialized in
xhci_resume() power_lost path?

Or is this related to audio offload and xhci sideband usage?

If we end up in this situation in normal headset resume failure then there
might be something else wrong.

Thanks
Mathias