All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes
Date: Mon, 13 Feb 2017 12:42:50 +0200	[thread overview]
Message-ID: <878tpaqslx.fsf@linux.intel.com> (raw)
In-Reply-To: <3cd92b82-7e30-0421-cd63-090000f4b610@denx.de>


Hi,

Marek Vasut <marex@denx.de> writes:
> On 02/10/2017 05:32 PM, Andy Shevchenko wrote:
>> From: Felipe Balbi <felipe.balbi@linux.intel.com>
>> 
>> If last packet is short, we shouldn't write req->length bytes to
>> non-volatile media, we should write only what's available to us, which
>> is held in req->actual.
>> 
>> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Since I have no clue about DFU internals, I will wait for Lukasz's Ack.

you don't need to have any clues about DFU internals to realise that
this fixes an actual bug, see below:

>>  drivers/usb/gadget/f_dfu.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
>> index 8e7c981657..64cdfa7c98 100644
>> --- a/drivers/usb/gadget/f_dfu.c
>> +++ b/drivers/usb/gadget/f_dfu.c
>> @@ -159,7 +159,7 @@ static void dnload_request_complete(struct usb_ep *ep, struct usb_request *req)
>>  	int ret;
>>  
>>  	ret = dfu_write(dfu_get_entity(f_dfu->altsetting), req->buf,
>> -			req->length, f_dfu->blk_seq_num);
>> +			req->actual, f_dfu->blk_seq_num);

DFU driver queues a request to USB controller. Per the gadget API
req->length contains maximum amount of data to be
transmitted. req->actual is written by USB controller with the actual
amount of data that we transmitted.

In the case of IN (TX), upon completion req->length and req->actual
should always be equal (unless errors show up, etc)

In the case of OUT (RX), upon completion req->actual MAY BE less than
req->length and that's not an error. Say host sent us a short packet
which causes early termination of transfer.

With that in mind, let's consider the situation where we're receiving
data from host using DFU. Let's assume that we have a 4096 byte buffer
for transfers and we're receiving a binary that's 7679 bytes in size.

Here's what we will do (pseudo-code):

int remaining = 7679;
char buf[4096];

while (remaining) {
	req->length = 4096;
        req->buf = buf;
        usb_ep_queue(req);

        /* wait for completion */

        remaining -= req->actual;

        dfu_write(buf, req->length);  /* this is the error */
}

Can you see here that in the last packet we will write 4096 bytes when
we should write only 3583?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170213/9bebe731/attachment.sig>

  reply	other threads:[~2017-02-13 10:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-10 16:32 [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes Andy Shevchenko
2017-02-10 17:50 ` Marek Vasut
2017-02-13 10:42   ` Felipe Balbi [this message]
     [not found] <de749db9-9d5c-4777-b4e9-2c0dd1840cb8@email.android.com>
2017-02-13 11:42 ` Felipe Balbi
2017-02-13 13:41   ` Lukasz Majewski
2017-02-13 15:02     ` Andy Shevchenko
2017-02-21 11:17     ` Felipe Balbi
2017-02-21 11:58       ` Lukasz Majewski
2017-02-21 12:58         ` Felipe Balbi
2017-02-21 13:21           ` Lukasz Majewski
2017-02-21 15:46             ` Felipe Balbi
2017-02-21 22:31               ` Lukasz Majewski
2017-02-22  9:21                 ` Felipe Balbi

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=878tpaqslx.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=u-boot@lists.denx.de \
    /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.