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

[Oliver Neukum]

On 27.10.26 08:38, Jiayi Li wrote:
> 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.

Even if an error occured? Does it make sense to wish to complete
commands that have failed while the driver is being unloaded. 
> However, the existing queue_work() calls already schedule these retries;
> flush_work() is not needed to enable them.

Indeed, but shouldn't we cancel scan_work _before_ we even try to complete
commands?

[..]
> > 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.

Understood. We need a genuine cancellation code.

> > 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.

Yes, but that doesn't answer you why you are setting resetting
only _after_ waiting for commands to complete.> 
> 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.

This answers it, but why do you unblock the device then at all?

	Regards
		Oliver