From patchwork Wed Jun 30 06:09:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Chiu X-Patchwork-Id: 1498753 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4GF9tc33Rlz9sXN; Wed, 30 Jun 2021 16:10:16 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1lyTQG-0004Tg-FI; Wed, 30 Jun 2021 06:10:08 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lyTQD-0004TO-FD for kernel-team@lists.ubuntu.com; Wed, 30 Jun 2021 06:10:05 +0000 Received: from 111-240-144-27.dynamic-ip.hinet.net ([111.240.144.27] helo=localhost.localdomain) by youngberry.canonical.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1lyTQC-0005Q9-Ql for kernel-team@lists.ubuntu.com; Wed, 30 Jun 2021 06:10:05 +0000 From: chris.chiu@canonical.com To: kernel-team@lists.ubuntu.com Subject: [PATCH 0/2][SRU][OEM-5.13/U] Fix Realtek USB hubs failure after resume in Dell WD19SC/DC/TB Date: Wed, 30 Jun 2021 14:09:47 +0800 Message-Id: <20210630060949.48025-1-chris.chiu@canonical.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Chris Chiu BugLink: https://bugs.launchpad.net/bugs/1928242 [Impact] All of 3 different WD19(TB/SC/DC) docks have 3 Type-A ports and 2 Type-C ports, and there're highspeed Hubs(0bda:5487 and its substream hub 0bda:5413) and Superspeed Hubs (0bda:0487 and its downstream hub 0bda:0413). In the bug description below, we will refer the 2 highspeed hubs as Hub A and Hub A.3, and the 2 superspeed hubs as Hub B and Hub B.3. All devices connected via either Type-A or Type-C ports will connect to either Hub A.3 or Hub B.3. If we connect a wakup enabled device (keyboard) to a Type-A port, the Hub A.3 will fail to activate after exiting s2idle and all downstream devices will not be detected. If we have a superspeed device connected to other Type-A port in addition to the keyboard, this superspeed device actually connects to Hub B.3, and the Hub B.3 will also fails to work after exiting s2idle. If the wakeup enabled device connects via Type-C port, there's no such problem. As a summary, a wakeup enabled device connect to Type-A port will cause the failure of Hub A.3 and Hub B.3. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. [Fix] Before the resume failure, the upstream hub(Hub A or B) will hit the timeout problem while doing SetPortFeature(PORT_SUSPEND) to the port of the downstream hub (Hub A.3 or Hub B.3). However, the PORT_SUSPEND bit of the wPortStatus is actually turned on for the Hub A.3, we simply need to make the kernel believe it's already suspended. Then the ClearPortFeature will be done during resume and the problem will go away. The Hub B.3 will be tricky. The PORT_SUSPEND bit is not on after the suspend timeout, but it needs the ClearPortFeature(PORT_SUSPEND) for Hub B.3 to avoid resume failure. It doesn't comply with the USB spec so it's hard to create a generic fix for it. Because it only happens when timeout happens on suspending Hub A.3 and there's a superspeed device connecting to Type-A port, we choose to leave it as-is and try to address it in the future. [Test Case] 1. Make sure that the WD19 connects to the laptop 2. Connect USB keyboard/mouse to USB Type-A ports. 3. Suspend the system 4. Press the Enter key or power button to wake up the system 5. Check if the USB keyboard/mouse are still working Repeat 4 and 5 for > 10 times w/o losing any USB devices. [Where problems could occur] A wakeup enabled device (keyboard) connect to Type-A port will cause the failure of Hub A.3 and Hub B.3 during resume. Hub B.3 only fails when a wakeup enabled device and a superspeed device both connect via Type-A port. All devices connects to Hub A.3 (and B.3 if superspeed device connect via Type-A port) will be lost after resume. Chris Chiu (2): USB: Verify the port status when timeout happens during port suspend Revert "USB: Add reset-resume quirk for WD19's Realtek Hub" drivers/usb/core/hub.c | 21 +++++++++++++++++++++ drivers/usb/core/quirks.c | 1 - 2 files changed, 21 insertions(+), 1 deletion(-) Acked-by: Krzysztof Kozlowski