From: Tom Rini <trini@konsulko.com>
To: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: u-boot@lists.denx.de, Lukasz Majewski <lukma@denx.de>,
Marek Vasut <marex@denx.de>,
U-Boot STM32 <uboot-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH] dfu: handle short frame result of UPLOAD in state_dfu_idle
Date: Fri, 28 Jan 2022 15:15:28 -0500 [thread overview]
Message-ID: <20220128201528.GL7515@bill-the-cat> (raw)
In-Reply-To: <20211013170053.1.I1158bd6d095c996f2dbd4b0aa9327e4eee202331@changeid>
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
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@foss.st.com>
Applied to u-boot/master, thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2022-01-28 20:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 15:01 [PATCH] dfu: handle short frame result of UPLOAD in state_dfu_idle Patrick Delaunay
2022-01-28 20:15 ` Tom Rini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220128201528.GL7515@bill-the-cat \
--to=trini@konsulko.com \
--cc=lukma@denx.de \
--cc=marex@denx.de \
--cc=patrick.delaunay@foss.st.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-stm32@st-md-mailman.stormreply.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.