Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2172237pxb; Thu, 3 Feb 2022 00:26:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJzs8oP0sXAEZBtOZHS69MRl8PyIGTB6JPtxw83Qv8As90pI6LcbIp/rWaATk4+QXtDyj12P X-Received: by 2002:a05:6a00:1749:: with SMTP id j9mr33134173pfc.83.1643876810030; Thu, 03 Feb 2022 00:26:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643876810; cv=none; d=google.com; s=arc-20160816; b=PVPFpDH0BL2EclIMvHW1Jq434VXNE0nvyJTd7PV5lIV9KWjzVCGwWBWUiFQLqL6vhR o5aaKfCKRzFLdZwcCVs83ClUkZ0SoWG6KI6vDS+qky7Bol2ESLsjoOHOJ4xDVeIONINg s6raqOVi80GOMu5RESEh3txRy4njRoDrCbNl6R9grLv9/OoKMD2p0p/TGLNpxFT0ZVH2 ZlBkXSS18OlK/4lp14fIqxH/LbpayVmvkeCmzu+m4WEdEGwkIFfuf7cCDwQQRYMgOMJ/ bfOoqus/stagLuXfGqigZv72EZarIPyqGOqkZVAnWDzbyXo+G3O12WkICb5seRYJdByn bqTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=utbvqXQyBkzZG663gcqksR4PHSbgvTPxbsM5EvgKhcQ=; b=BWDIm7wocsL/3UfLta0AR8K9SJgDbDWk/wksqAVZGLrfhSbIBedIXCP5IeEEIlWPFa 0VpDs/fErTTqutRPJaAnAJ7nBX1PSDFsU3fzCOapmFoJ4GLoytOdZy4KUbVGEEeLHl8Q Ird976b8qGA46iemOpVKjAdxfME2/OJ7vhHHrryXh2/Nvq98tzrqtt1LZZ9uLccFxYlL AcoEf845aLXEkMa5WVR19cKSKVjan29kDbnll2mftPzn0C3a2nivjJpe47dxrSOZh2+I E0P4OUYSP3+3rZ/Tydhuq8Xm0dfolUCw6aA59mautIyQ04fxAgArtShka/77Uk/N/tHC Ok7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=ctsG6UDF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m15si21407285pfc.252.2022.02.03.00.26.38; Thu, 03 Feb 2022 00:26:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=ctsG6UDF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236186AbiBCIAi (ORCPT + 99 others); Thu, 3 Feb 2022 03:00:38 -0500 Received: from alexa-out.qualcomm.com ([129.46.98.28]:12472 "EHLO alexa-out.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241935AbiBCIAd (ORCPT ); Thu, 3 Feb 2022 03:00:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1643875234; x=1675411234; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=utbvqXQyBkzZG663gcqksR4PHSbgvTPxbsM5EvgKhcQ=; b=ctsG6UDF/SDSmw9SzP3s/72ci6K5huKw86cJDo9QByP0sa9piADT6fek jMeVs909Q0cHzEHgo2JgvvozejWj/SZFKWXqgT+eiXebPDy987AgTO8wm VwKcHUueCFL+b5wPv08SLc3oc92gQOgJUUC58UBukLDZmz+Soo4lqTkOl c=; Received: from ironmsg07-lv.qualcomm.com ([10.47.202.151]) by alexa-out.qualcomm.com with ESMTP; 03 Feb 2022 00:00:33 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg07-lv.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2022 00:00:33 -0800 Received: from nalasex01b.na.qualcomm.com (10.47.209.197) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Thu, 3 Feb 2022 00:00:32 -0800 Received: from wcheng-linux.qualcomm.com (10.80.80.8) by nalasex01b.na.qualcomm.com (10.47.209.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Thu, 3 Feb 2022 00:00:32 -0800 From: Wesley Cheng To: , CC: , , , , Wesley Cheng Subject: [RFC PATCH 0/3] Fix enumeration issues during composition switching Date: Thu, 3 Feb 2022 00:00:14 -0800 Message-ID: <20220203080017.27339-1-quic_wcheng@quicinc.com> X-Mailer: git-send-email 2.33.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01b.na.qualcomm.com (10.47.209.197) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch series addresses a few enumeration issues being seen during fast composition switching test cases: - Missing DWC3 core soft reset before run/stop enable. Recommended by the Synopsis databook to do this during the pullup enable case. - Endxfer command timeouts leading to controller halt failures in the pullup disable path. - Endxfer command timeouts leading to EP dequeue to never return a completion to the function drivers, which can cause to unbind issues depending on function driver implementation. With regards to the endxfer timeout, it was communicated to us that if there is a pending setup/control transfer in progress, the DWC3 controller is unable to service the endxfer command for other endpoints. USB bus sniffer and USB ftrace logs confirmed that when the endxfer timeouts occurred, there was a SETUP token being sent by the host, while the pullup routine was in progress, as during the pullup disable, we should not see any ftrace logs since IRQs are disabled. It was recommended by Synopsis to ensure that packets on EP0 are always handled, and the only way to drain the dedicated control transfer internal memory is to issue a startxfer command. With this in mind, the pullup disable case is able to discard any cached setup packets (as disconnect would pursue), so the approach to issue a startxfer after an unsuccessful endxfer is possible. Test logs show the subsequent endxfer is successful: [004] d..1 15631.849982: dwc3_gadget_ep_cmd: ep1out: cmd 'End Transfer' [20c08] params 00000000 00000000 00000000 --> status: Timed Out [004] d..1 15631.850008: dwc3_prepare_trb: ep0out: trb ffffffc019dad000 (E0:D0) buf 00000000efffa000 size 8 ctrl 00000c23 (HLcs:SC:setup) [004] d..1 15631.850024: dwc3_gadget_ep_cmd: ep0out: cmd 'Start Transfer' [406] params 00000000 efffa000 00000000 --> status: Successful [004] d..1 15631.857380: dwc3_gadget_ep_cmd: ep1out: cmd 'End Transfer' [20c08] params 00000000 00000000 00000000 --> status: Successful [004] d..1 15631.857409: dwc3_gadget_giveback: ep1out: req ffffff8789212300 length 0/16384 zsI ==> -108 Attempts to ensure EP0 transfers don't happen during pullup disable were added as well. For the dequeue path, since usb_ep_dequeue() can be called from the function driver at any time, the same approach can not be used. In this case, if there is an endxfer failure observed when dequeuing a request, mark the endpoint w/ a flag, which will be later checked when the control transfer is complete. From there it will traverse through all EPs to service the ones that need to re-issue the endxfer command. This logic will only trigger if there is at least one EP that needs servicing. Wesley Cheng (3): usb: dwc3: Flush pending SETUP data during stop active xfers usb: dwc3: gadget: Wait for ep0 xfers to complete during dequeue usb: dwc3: Issue core soft reset before enabling run/stop drivers/usb/dwc3/core.c | 4 +- drivers/usb/dwc3/core.h | 14 ++++++ drivers/usb/dwc3/ep0.c | 23 ++++++--- drivers/usb/dwc3/gadget.c | 100 +++++++++++++++++++++++++++++++++----- 4 files changed, 118 insertions(+), 23 deletions(-)