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

[Alan Stern]

On Sun, Sep 20, 2026 at 09:23:58AM +0800, Jiayi Li wrote:
> What this patch does:
> 
>   - set soft_unbind so endpoints remain available during driver-only
>     unbind;
>   - cancel pending scanning before removing the SCSI host;
>   - for driver-only unbind, remove the SCSI host before setting resetting,
>     killing the anchored URBs and freeing streams;
>   - for physical disconnect, retain the existing kill-first order because
>     the endpoints are no longer usable.
> 
> This follows the broad ordering used by usb-storage, which sets
> soft_unbind and removes its SCSI host before releasing transport
> resources.

> Open questions for RFC discussion:
> 
> The change above fixes the reproduced failure, but it is not clear whether
> this is the best way to handle driver-only unbind in uas.
> 
>   1. Is enabling soft_unbind and moving scsi_remove_host() ahead of URB
>      teardown acceptable for driver-only unbind?

Not speaking for the uas maintainers, I should think it is both 
acceptable and necessary for any USB mass-storage driver.

>   2. Is there a more appropriate way to quiesce SCSI commands and UAS
>      streams before endpoint teardown?

Not that I know of.  If you don't tell it to remove the host, the SCSI 
subsystem will simply continue to try sending commands to the driver.

>   3. If this ordering is acceptable, does the driver-only unbind path need
>      a bounded fallback when scsi_remove_host() encounters a nonresponsive
>      device or ongoing SCSI error handling?

In general, a class driver like uas shouldn't care whether an unbind is 
what you call "driver-only".  It should take the same steps whether it 
can communicate with the device or not.  (Note that the patch's test for 
USB_STATE_NOTATTACHED isn't fully reliable -- there is a window after a 
device is unplugged before the state gets updated.)

But to answer your question: No.  Rely on the SCSI subsystem to handle 
its own host removal properly.  If, in your opinion, it's not doing a 
good job then you can submit patches to the SCSI maintainers to improve 
the situation.

Alan Stern