From patchwork Mon Jul 2 19:48:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerry Zhang X-Patchwork-Id: 10502311 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1D9196035E for ; Mon, 2 Jul 2018 19:48:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BBD028A47 for ; Mon, 2 Jul 2018 19:48:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F180128A5C; Mon, 2 Jul 2018 19:48:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9567728A47 for ; Mon, 2 Jul 2018 19:48:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752977AbeGBTsk (ORCPT ); Mon, 2 Jul 2018 15:48:40 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:45261 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752945AbeGBTsj (ORCPT ); Mon, 2 Jul 2018 15:48:39 -0400 Received: by mail-pl0-f67.google.com with SMTP id bi1-v6so8408006plb.12 for ; Mon, 02 Jul 2018 12:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=o9WU6TYLWeZEz9/m63T51Cjy6iIxRRj+lE0F42r/pPo=; b=eCSilQkex96kv00edOC2fgwTC7irNcOpdLaKEsablHq79TbB15zbkwNfJGhAc1l2Yo urvkQ7JGekDGyqSeVPULUXzXStSEKQn13gfPvX6JGoi/fJmX0C9PclMGpUWdwHU8bZx+ wwG9J1vgsaJpCuc2kO1FuUg/+ZKvBZQZdSQttLO9O0cG4WEDFrNMrholYag3z2SSAPh/ 6aZ3/NUXAT5CxGBpcud9IOtkSSGoaPD1IH+vEDkk1ds4dHEVSvgmECyIJTMulwYIB1w+ Xoh2yHyMws3toU5t/6tMUUhABkYPVTbME+dy3Sp8EZU2yuWBOOYn43gkCm4VkVXt+HUA oreg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=o9WU6TYLWeZEz9/m63T51Cjy6iIxRRj+lE0F42r/pPo=; b=LVHu0iFMQ/18HWIzT7qdM5Ba7a37myGQHFPN974EeWFLtsWTCVJPZp378XfBqHwffT AEh0ZgZSGE+YoPIqtARliJMI/vg/9YBRIKFyzP/wIcE80tCTHCbJPBiMDuD+LIRu2AZB NGZGA3DtvHjSwjHZZXWtGHigTCuhQQqiRqW198NKPOWQV8k2LtMurNcpNPTSRfYuk+SY OyiF3hiAva3RoCy23mmxlLPlgLxiLTFIb839ImYL8JFepu4jf5j9hqicLmUhYCrnxSOX X+LmtkqEHmZrvHvPZYF4Vf2+oFY2EJAR8+AYLtL6wziBBH8ff/n3tIEnf7NgOKI+qE1R 5vCA== X-Gm-Message-State: APt69E2VnF/vYZR/adrC21xzydhGgfmEBfMEtGpy4SNI0Mac8sBizack AyUVMvadZpwe6EetQ+6gX6P0jg== X-Google-Smtp-Source: AAOMgpe02bNX/eHJAXL6QIjn/JxKGAdCL+QPASO95EOlL8vN0a5XpcgP9ePrLPoYwoB//NEQ8+rToQ== X-Received: by 2002:a17:902:8f96:: with SMTP id z22-v6mr2138282plo.190.1530560918682; Mon, 02 Jul 2018 12:48:38 -0700 (PDT) Received: from zhangjerry.mtv.corp.google.com ([2620:0:1000:1611:ee20:2649:babf:1d14]) by smtp.gmail.com with ESMTPSA id v1-v6sm14836502pfg.101.2018.07.02.12.48.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 12:48:38 -0700 (PDT) From: Jerry Zhang To: Felipe Balbi , Michal Nazarewicz , Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org, zhangjerry@google.com, jerryxzha@gmail.com Subject: [PATCH] usb: gadget: f_fs: Only return delayed status when len is 0 Date: Mon, 2 Jul 2018 12:48:08 -0700 Message-Id: <20180702194808.157636-1-zhangjerry@google.com> X-Mailer: git-send-email 2.18.0.399.gad0ab374a1-goog Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Commit 1b9ba000 ("Allow function drivers to pause control transfers") states that USB_GADGET_DELAYED_STATUS is only supported if data phase is 0 bytes. It seems that when the length is not 0 bytes, there is no need to explicitly delay the data stage since the transfer is not completed until the user responds. However, when the length is 0, there is no data stage and the transfer is finished once setup() returns, hence there is a need to explicitly delay completion. This manifests as the following bugs: Prior to 946ef68ad4e4 ('Let setup() return USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs would require user to queue a 0 byte request in order to clear setup state. However, that 0 byte request was actually not needed and would hang and cause errors in other setup requests. After the above commit, 0 byte setups work since the gadget now accepts empty queues to ep0 to clear the delay, but all other setups hang. Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS") Signed-off-by: Jerry Zhang Acked-by: Felipe Balbi --- This patch used to be in a set, but is being submitted standalone for the next 4.18 rc. drivers/usb/gadget/function/f_fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 4e47e8c58067..a6868f936c78 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3281,7 +3281,7 @@ static int ffs_func_setup(struct usb_function *f, __ffs_event_add(ffs, FUNCTIONFS_SETUP); spin_unlock_irqrestore(&ffs->ev.waitq.lock, flags); - return USB_GADGET_DELAYED_STATUS; + return creq->wLength == 0 ? USB_GADGET_DELAYED_STATUS : 0; } static bool ffs_func_req_match(struct usb_function *f,