firehose: give the UFS provisioning commit a longer timeout

[igoropaniuk]

UFS provisioning drives the programmer with three tags: a common tag, one or more body tags, and an epilogue. The epilogue is sent twice

• first with commit=0 to validate the requested layout, then with commit=1 to actually write the UFS configuration descriptor to the device. All of these tags went through firehose_send_single_tag(), which waited only 5s for the .

The commit=1 epilogue is the only expensive step: it makes the programmer write the configuration descriptor to the device, which can take considerably longer than 5s. When it does, the device emits its "Calling handler for ufs" log but has not answered with an ACK yet, so firehose_read() times out, firehose_send_single_tag() reports the tag as failed, and provisioning is aborted even though the device is still working. The program/erase write-back paths already use a 120s timeout for exactly this reason; the UFS commit needs the same treatment.

Thread a timeout into firehose_send_single_tag() and use a short 5s wait for the cheap common/body/validation tags while giving the commit epilogue a 120s window. The commit=0 validation pass keeps the short timeout.

Observed failure before the fix:

$ qdl --storage ufs prog_firehose_ddr.elf provision_ufs31.xml --debug
...
FIREHOSE WRITE:

FIREHOSE READ:


LOG: INFO: Calling handler for ufs
ufs request failed
failed to apply ufs epilogue
UFS provisioning failed

[JohnSagaQuic]

I reviewed firehose.c and noticed a possible issue in firehose_apply_ufs_epilogue(), line 1517.
The function waits up to 120 seconds for an ACK. If the device resets the USB connection before the ACK is received, firehose_read() returns -EIO, which causes the read loop to exit. As a result, firehose_send_single_tag() returns a non-ACK value, leading firehose_apply_ufs_epilogue() to report "failed to apply ufs epilogue" and return -1, even though UFS provisioning may have completed successfully.
Would it make sense to treat -EIO during the commit epilogue response as a potential success case, since a device reset at that stage may be expected?