Re: [PATCH v2] usb: uas: wait for pending commands before unbinding

[Jiayi Li]

Hi,

Thank you for the review.

On Mon, Oct 26, 2026, Oliver Neukum wrote:
> 1. If an error happens while disconnect is running, why do we want to schedule
> work?
> 2. Why only this and not also scan_work?

devinfo->work retries allocation and URB submission for commands already
accepted by UAS. Those commands may need further URBs submitted before
they can complete, so I intended to allow that work to continue while
new SCSI requests are blocked.

However, the existing queue_work() calls already schedule these retries;
flush_work() is not needed to enable them.

I tested removing only this flush_work() call, leaving the worker and
retry logic unchanged. Normal reads and commands with controlled
allocation failures that later recovered still completed successfully.
With controlled persistent allocation or submission failures, preparation
timed out and the existing cleanup completed. Subsequent rebinds and reads
also succeeded. I will therefore remove this call in the next revision.

> Some commands run longer

Yes. This is intended as a best-effort grace period before cancellation.
The timeout values were taken from uas_wait_for_pending_cmnds(); they
were not selected to cover the maximum duration of every SCSI command.

If a command remains unfinished when preparation times out, the
existing cleanup proceeds. An affected bridge may still require a
physical disconnect and reconnect in that case.

> Is the resetting flag even needed anymore?
> If it is needed, why set it so late?

resetting is still needed before scsi_unblock_requests(), so requests
dispatched during the remaining teardown cannot submit new URBs.

Setting it before preparation also prevents the submission worker from
progressing and makes the status and data callbacks skip normal command
completion processing. In the hardware comparison with the flag set
earlier, the URBs returned, but the command table remained populated
until preparation timed out.

The intended order is therefore to block new requests, allow accepted
commands to finish, then set resetting before unblocking the host and
performing the final cleanup.

Thanks,
Jiayi