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