[PATCH] dfu: handle short frame result of UPLOAD in state_dfu_idle

[Tom Rini]

On Wed, Oct 13, 2021 at 05:01:37PM +0200, Patrick Delaunay wrote:

> In DFU v1.1 specification [1] the DFU_UPLOAD (Short Frame)
> is handled only in dfuUPLOADIDLE state:
> 
> - Figure A.1 Interface state transition diagram
> 
> - the state description in chapter A.2
> 
> A.2.3 State 2 dfuIDLE
>   on Receipt of the DFU_UPLOAD request,and bitCanUpload = 1
>   the Next State is dfuUPLOADIDLE
> 
> A.2.10 State 9 dfuUPLOAD-IDLE
>   When the length of the data transferred by the device in response
>   to a DFU_UPLOAD request is less than wLength. (Short frame)
>   the Next State is dfuIDLE
> 
> In current code, when an UPLOAD is completely performed after the first
> request (for example with wLength=200 and data read = 9), the DFU state
> stay at dfuUPLOADIDLE until receiving a DFU_UPLOAD or a DFU_ABORT request
> even it is unnecessary as the previous DFU_UPLOAD request already reached
> the EOF.
> 
> This patch proposes to finish the DFU uploading (don't go to dfuUPLOADIDLE)
> and completes the control-read operation (go to DFU_STATE_dfuIDLE) when
> the first UPLOAD response has a short frame as an end of file (EOF)
> indicator even if it is not explicitly allowed in the DFU specification
> but this seems logical.
> 
> [1] https://www.usb.org/sites/default/files/DFU_1.1.pdf
> 
> Signed-off-by: Patrick Delaunay <patrick.delaunay at foss.st.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220128/5b170c27/attachment.sig>