From patchwork Mon Jun 3 10:53:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jim Lin X-Patchwork-Id: 10972747 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0FCA376 for ; Mon, 3 Jun 2019 10:54:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 007BF2872F for ; Mon, 3 Jun 2019 10:54:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E864D287CD; Mon, 3 Jun 2019 10:54:04 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI 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 932822872F for ; Mon, 3 Jun 2019 10:54:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727427AbfFCKxu (ORCPT ); Mon, 3 Jun 2019 06:53:50 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:8626 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726272AbfFCKxu (ORCPT ); Mon, 3 Jun 2019 06:53:50 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 03 Jun 2019 03:53:49 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Mon, 03 Jun 2019 03:53:49 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Mon, 03 Jun 2019 03:53:49 -0700 Received: from HQMAIL108.nvidia.com (172.18.146.13) by HQMAIL106.nvidia.com (172.18.146.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Jun 2019 10:53:49 +0000 Received: from hqnvemgw01.nvidia.com (172.20.150.20) by HQMAIL108.nvidia.com (172.18.146.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 3 Jun 2019 10:53:49 +0000 Received: from jilin-desktop.nvidia.com (Not Verified[10.19.120.158]) by hqnvemgw01.nvidia.com with Trustwave SEG (v7,5,8,10121) id ; Mon, 03 Jun 2019 03:53:49 -0700 From: Jim Lin To: , , , , , , , , CC: , , Jim Lin Subject: [PATCH v11 0/2] usb: xhci: Add Clear_TT_Buffer Date: Mon, 3 Jun 2019 18:53:42 +0800 Message-ID: <1559559224-9845-1-git-send-email-jilin@nvidia.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1559559229; bh=9P1Kz4O/jSg8ZsRPR4q5epOTj+e9MWcHICCyeQn5/x0=; h=X-PGP-Universal:From:To:CC:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type; b=Jve8nrfVwxJobxASp2dTcAa3Z7ZNIc91pgaPzEsHwZ4Ni88VoibUPnMR9Ir/gWM4r NEM34cqCVIE0omtVCrSE/QHZ/NYnIGdhmaSEJflh6zuLZRFxSVkT1YVo4X30DP6pIX ZKkwGnj5IbAhGwaTguCMjlln1o7eSZsNzFcyHBqHS7rUlgZoqO6GxYmGq5Iyv+2Kw+ QRcf1XVuCPZymq/s1AbayMJ/lB1FtyK+Gr71r1AsH9CLzpxOBA4h/jUt9vwmU/lXOE vWUq8kknSt8g5StXejsn/xv4HImh+quSNHalNSkQ3FjKxGlCAQ/W7jQnD9owMTtTF3 NJUSmWUi0Ye7w== 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 USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt processing for full-/low-speed endpoints connected via a TT, the host software must use the Clear_TT_Buffer request to the TT to ensure that the buffer is not in the busy state". In our case, a full-speed speaker (ConferenceCam) is behind a high- speed hub (ConferenceCam Connect), sometimes once we get STALL on a request we may continue to get STALL with the folllowing requests, like Set_Interface. Solution is to invoke usb_hub_clear_tt_buffer() to send Clear_TT_Buffer request to the hub of the device for the following Set_Interface requests to the device to get ACK successfully. The Clear_TT_Buffer request sent to the hub includes the address of the LS/FS child device in wValue field. usb_hub_clear_tt_buffer() uses udev->devnum to set the address wValue. This won't work for devices connected to xHC. For other host controllers udev->devnum is the same as the address of the usb device, chosen and set by usb core. With xHC the controller hardware assigns the address, and won't be the same as devnum. Here we have two patches. One is to add devaddr in struct usb_device for usb_hub_clear_tt_buffer() to use. Another is to invoke usb_hub_clear_tt_buffer() for halt processing. Signed-off-by: Jim Lin Jim Lin (2): usb: Add devaddr in struct usb_device usb: xhci: Add Clear_TT_Buffer drivers/usb/core/hub.c | 4 +++- drivers/usb/host/xhci-ring.c | 27 ++++++++++++++++++++++++++- drivers/usb/host/xhci.c | 23 +++++++++++++++++++++++ drivers/usb/host/xhci.h | 5 +++++ include/linux/usb.h | 2 ++ 5 files changed, 59 insertions(+), 2 deletions(-) Acked-by: Alan Stern