From patchwork Fri Feb 1 12:52:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan-Marek Glogowski X-Patchwork-Id: 10792673 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 82F00746 for ; Fri, 1 Feb 2019 12:52:43 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6FC76320CF for ; Fri, 1 Feb 2019 12:52:43 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 63AD2320D6; Fri, 1 Feb 2019 12:52:43 +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.9 required=2.0 tests=BAYES_00,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 6FC7F320D0 for ; Fri, 1 Feb 2019 12:52:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726737AbfBAMwl (ORCPT ); Fri, 1 Feb 2019 07:52:41 -0500 Received: from ironboyv.h-da.de ([141.100.10.230]:9105 "EHLO ironboyv.h-da.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725837AbfBAMwk (ORCPT ); Fri, 1 Feb 2019 07:52:40 -0500 IronPort-SDR: Q3XTa6Q0DW/s3eCnU/I3zuDSP1lIDpg3TF+YqUE6ZnVQsyyoZoAdD6XvjPMdjQT4FQFJbSmftP Ag6Y5QegwdJl01FMYsLuaXvNXs6okISferhKYphFTbLcMC09DP6dGZn5IciO6tllxg/kgmTAWN +xV9aNu6F5amasRzDpX5gQp1uUKjWcXKOW5LadG7x7KSJzHMpxTO78HtWBJQJ5aIr9WHg2L+PA 3fB6TH/qftlxNC5qS3DjCSIMKvp0h5o77KtjzejBjRd0NwZleRkSS3Ep094NTSXZdGegOM6d1H HdA= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2FpAAC6QFRc/2soZI1jHAEBAQQBAQcEAQGBUwUBAQsBggOBODInmBBMAQEBAQEHmUMUgWc5hECDEyI2Bw0BAwEBAgEBAgICaSiFeVIogSkcgwaBdRGqdzMaAooah3+EQRd4gQeBEIRUAYMoA2GFEwKJcQGCApZzCYEckRwXij0ZA4dmAYMvmhkBMYFWTSQUgyeCKAwLjh8+M4EfiSoBJQOCJAEB X-IPAS-Result: A2FpAAC6QFRc/2soZI1jHAEBAQQBAQcEAQGBUwUBAQsBggOBODInmBBMAQEBAQEHmUMUgWc5hECDEyI2Bw0BAwEBAgEBAgICaSiFeVIogSkcgwaBdRGqdzMaAooah3+EQRd4gQeBEIRUAYMoA2GFEwKJcQGCApZzCYEckRwXij0ZA4dmAYMvmhkBMYFWTSQUgyeCKAwLjh8+M4EfiSoBJQOCJAEB Received: from unknown (HELO mail.fbihome.de) ([141.100.40.107]) by ironboyv.h-da.de with ESMTP; 01 Feb 2019 13:52:37 +0100 Received: from kvm-sbuild2.tvc.muenchen.de. (unknown [194.113.41.246]) by mail.fbihome.de (Postfix) with ESMTPSA id 2B1324224F; Fri, 1 Feb 2019 13:51:35 +0100 (CET) From: Jan-Marek Glogowski To: linux-usb@vger.kernel.org Cc: Greg Kroah-Hartman , Alan Stern , Mathias Nyman , Kai-Heng Feng , Nicolas Boichat , Nicolas Saenz Julienne , Jon Flatley , Oliver Neukum Subject: [PATCH] usb: handle warm-reset port requests on hub resume Date: Fri, 1 Feb 2019 13:52:31 +0100 Message-Id: <1549025551-4306-1-git-send-email-glogow@fbihome.de> X-Mailer: git-send-email 2.1.4 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 On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the port status requests a warm-reset this way. This just happens, if its the only device on the root hub, the hub therefore resumes and the HCDs status_urb isn't yet available. If a warm-reset request is detected, this sets the hubs event_bits, which will prevent any auto-suspend and allows the hubs workqueue to warm-reset the port later in port_event. Signed-off-by: Jan-Marek Glogowski Acked-by: Alan Stern --- The original thread is "USB-C storage device not detected on USB 3.1 Gen 2 host when plugged in after boot". A different patch, suggested by Mathias Nyman, didn't work for me. This patch was just rebased on usb-next, but not re-tested. Original tests are based on 5.0-rc. v1: This always warm-resets the ports in hub_activate, independent of the "enum hub_activation_type". Just had a single device to test. v2: I had the idea about the working device, if there is already a device connected to the hub and that a resume only on "type == HUB_RESUME" should be sufficient. This still works for me, but I didn't follow all the hub_activate callers everywhere and I'm definitly still missing a lot of knowledge about USB stuff. There is also HUB_RESET_RESUME with a slightly different code path. I don't know how to trigger this. v3: code unchanged to v2. v4: instead of handling the warm-reset directly from hub_activate by calling hub_port_reset, this defers the reset by setting the hubs event_bits of the port. --- drivers/usb/core/hub.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index bb0830c..8d4631c 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -108,6 +108,8 @@ EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem); static void hub_release(struct kref *kref); static int usb_reset_and_verify_device(struct usb_device *udev); static int hub_port_disable(struct usb_hub *hub, int port1, int set_state); +static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1, + u16 portstatus); static inline char *portspeed(struct usb_hub *hub, int portstatus) { @@ -1137,6 +1139,11 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type) USB_PORT_FEAT_ENABLE); } + /* Make sure a warm-reset request is handled by port_event */ + if (type == HUB_RESUME && + hub_port_warm_reset_required(hub, port1, portstatus)) + set_bit(port1, hub->event_bits); + /* * Add debounce if USB3 link is in polling/link training state. * Link will automatically transition to Enabled state after