From patchwork Wed Oct 13 15:01:37 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Delaunay X-Patchwork-Id: 1540453 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=foss.st.com header.i=@foss.st.com header.a=rsa-sha256 header.s=selector1 header.b=KMVsgar9; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4HTwjh2WJXz9sS8 for ; Thu, 14 Oct 2021 02:01:58 +1100 (AEDT) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 406F8835A1; Wed, 13 Oct 2021 17:01:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=foss.st.com header.i=@foss.st.com header.b="KMVsgar9"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 308D681761; Wed, 13 Oct 2021 17:01:48 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id AD7668358A for ; Wed, 13 Oct 2021 17:01:44 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=prvs=49201cc72d=patrick.delaunay@foss.st.com Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19DDKX9a011459; Wed, 13 Oct 2021 17:01:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=selector1; bh=jhab7mR9ZMYgNR1RBQTrmwsgteiVIZvDdDKBkEq5gKs=; b=KMVsgar9LZAytkX1FOp/BhfkMekvAx5+s1jJt2eF/w1WjNT7lD8+abU1RHebqXplR4f7 RBQzLIqQKamPPs/Uwk8dWhZtYtD7edx5pZamXvZTaMXB/R5jcKPgt5ZQ02TAgAQfKtNA dEK/CwKwrADchzfkiuqHZPn56zKp2+U8aNT6RV7qFY3SZ5P6lnkVqmF6PcA981HgD5om 7aRn+RvVou0rUUmmKxFMOBuRiKgp+Y6tf9Fhxecfvji4UgQSJ/F99LjbIp95TZoWdOV6 QKl3bx5zKf1K4trEfDP12ZnfhUrxT8hrFMBbhLbDmP2w2nZmV/X1PR0lXDm4ge7hCEn0 2g== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 3bnuxttrek-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Oct 2021 17:01:43 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 87F4910002A; Wed, 13 Oct 2021 17:01:42 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag2node2.st.com [10.75.127.5]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 5E873231509; Wed, 13 Oct 2021 17:01:42 +0200 (CEST) Received: from localhost (10.75.127.44) by SFHDAG2NODE2.st.com (10.75.127.5) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 13 Oct 2021 17:01:41 +0200 From: Patrick Delaunay To: CC: Lukasz Majewski , Patrick Delaunay , Marek Vasut , U-Boot STM32 Subject: [PATCH] dfu: handle short frame result of UPLOAD in state_dfu_idle Date: Wed, 13 Oct 2021 17:01:37 +0200 Message-ID: <20211013170053.1.I1158bd6d095c996f2dbd4b0aa9327e4eee202331@changeid> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.75.127.44] X-ClientProxiedBy: SFHDAG2NODE2.st.com (10.75.127.5) To SFHDAG2NODE2.st.com (10.75.127.5) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-13_06,2021-10-13_02,2020-04-07_01 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean 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 --- Hi Lukasz, This case is correctly handle in dfu-util, see dfu_load.c dfuload_do_upload() { .... while (1) { ... rc = dfu_upload(dif->dev_handle, dif->interface, xfer_size, transaction++, buf); .... dfu_file_write_crc(fd, 0, buf, rc); total_bytes += rc; if (total_bytes < 0) errx(EX_SOFTWARE, "\nReceived too many bytes (wraparound)"); if (rc < xfer_size) { /* last block, return */ ret = 0; break; } } } In the upload loop the code doesn't make difference for the first request and the next one: the last block is detected as soon as the received data < requested size. So it is safe to do the same in U-Boot's DFU stack, skip the dfuUPLOADIDLE state when the upload operation is finished after the first request. This patch avoid to ABORT the unfinished UPLOAD request before the next command. This patch was previously sent as RFC = [RFC] dfu: handle short frame result of UPLOAD in state_dfu_idle http://patchwork.ozlabs.org/project/uboot/list/?series=248838&state=* Patrick. drivers/usb/gadget/f_dfu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c index 4bedc7d3a1..e9340ff5cb 100644 --- a/drivers/usb/gadget/f_dfu.c +++ b/drivers/usb/gadget/f_dfu.c @@ -336,6 +336,8 @@ static int state_dfu_idle(struct f_dfu *f_dfu, f_dfu->dfu_state = DFU_STATE_dfuUPLOAD_IDLE; f_dfu->blk_seq_num = 0; value = handle_upload(req, len); + if (value >= 0 && value < len) + f_dfu->dfu_state = DFU_STATE_dfuIDLE; break; case USB_REQ_DFU_ABORT: /* no zlp? */