Re: [PATCH v2] usb: uas: quiesce SCSI before stopping endpoints on unbind

From: Oliver Neukum

Date: Wed Sep 30 2026 - 03:23:38 EST


Hi,

thank you for pursuing this issue.

On 30.09.26 03:33, Jiayi Li wrote:
Hi Oliver,

Acked-by: Oliver Neukum <oneukum@xxxxxxxx>

Thank you for the Acked-by. Subsequent testing found a regression in
v2: physically unplugging the device with UAS commands in flight can
cause an approximately 30-second SCSI timeout. I described the failure

This can happen. Don't be discouraged.

in my reply to the Sashiko review:

https://lore.kernel.org/linux-scsi/20260922100542.164047-1-lijiayi@xxxxxxxxxx/

I have a local candidate that keeps the unified teardown order.

Highly important.

When URB submission or completion returns -ENODEV or -ESHUTDOWN,
it marks the transport dead, stops further submissions, clears

Why this specific trigger?
I am asking because -ENODEV comes relatively late in the process.
URBs tend to fail long before that.

COMMAND_INFLIGHT and sets DID_NO_CONNECT for pending commands.
It drains the remaining URBs in work context, allowing the commands
to complete through uas_try_complete().

In the context of which work?

Does this approach seem reasonable, or would you suggest a simpler
way to handle the physical-disconnect case?

I definitely have no simpler way to handle physical disconnect.
With what you describe, while the approach seems entirely reasonable,
I wonder what is to be done if error handling has already started
on the SCSI level.

Regards
Oliver