From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Date: Tue, 21 Feb 2017 13:17:04 +0200 Subject: [U-Boot] [PATCH v1] usb: gadget: f_dfu: write req->actual bytes In-Reply-To: <20170213144102.37d73a16@jawa> References: <87wpcupb9t.fsf@linux.intel.com> <20170213144102.37d73a16@jawa> Message-ID: <87shn7x07j.fsf@linux.intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Lukasz, Lukasz Majewski writes: >> > >> 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? >> > >> > In principle you are right. I need to check if this change will not >> > introduce regressions. >> > >> > Can you share your use case? >> >> Intel Edison running v2017.03-rc1 + patches (see [1]), flashing >> u-boot.bin over DFU (see [2] for details). Without $subject, image has >> to be aligned to 4096 bytes as below: >> >> $ dd if=u-boot.bin of=u-boot-4k.bin bs=4k seek=1 && truncate -s %4096 >> u-boot-4k.bin >> >> With $subject, I don't need truncate. We still need the 4096 byte of >> zeroes in the beginning of the image for other reasons (which I really >> don't know why at this point). >> >> [1] https://github.com/andy-shev/u-boot/tree/edison >> [2] https://communities.intel.com/message/435516#435516 >> > > Ok. I will check this. Thanks for pointing out :-) Any updates here? I'd like to send Tangier Soc and Intel Edison Board support but I kinda depend on this patch making upstream. I can resend as part of the "add intel edison" series. Let me know -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: