Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp557163ybi; Fri, 24 May 2019 07:55:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqzKgyGnFECO6h27WVMAEkggnBJ8ZpoVjaV04YW/7REsX2ddug3wJGQYLwUlkKwgd20mLQnv X-Received: by 2002:a65:4c4c:: with SMTP id l12mr102243066pgr.404.1558709746242; Fri, 24 May 2019 07:55:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558709746; cv=none; d=google.com; s=arc-20160816; b=tFFbvMx5iMpS76jNgEHOa4kYpJGePd18s32lF5ykwrx1lFjyatZQZvcmykfA91TWi0 mE0SPb74nZzHxksMdrf58o9dW4M5/61uioFpuobVmlkODCsxDsC0gFvD2eXq5Yh2jQ+p 2CN4Q/JXU8xXU7n2ILtDlm34q//FZLQ5c9o/0E7JoOUAkGxWbYxOyJofMeCj5BkyVch5 XNkUT+TXEOUcVg9oztiMYrS4bm0O7wwCfavGNOP1Ivyzx0ojXhv9veq5qpmvfl+iVE9Q DP41P0J/TN+Yu9gdmrr2+Zf1Xo5O+LUxX6gbUIoA5i3xSt4xL14/MiAFQUpam5/K2ePa lDqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=7M+dTLJA8hhtnnD8K0PHvhQiy843IdwjSQ/K3QBEXcQ=; b=Yeo8CjI/3qvpthEf9sGfRMj1VsvApRjg8pU7Qu+9Zq7a7bq04x1S5MVsdbC9f/X4oC gyLk5X8pWG5xzR9DTuUlid0PlYp1CiP2i+UbbZG4Dnb9sEkyp3p/M1mzrUrxypjeegJ7 aEEvARPVg2516p1omVi2sRtZn5WtM7bEJWcQPN8Ke/kWr2cJtAeDIQMl+/hSmA4ZX09Q YJ7VhoPzeHwEIQFAi2TQ8UXQXntt5pR7n7CRFfe0Jb6BrjlJtNgJccXg5/WpWFJKUcQl eVnW2/jLcF86xXMPMGkEGVobV79DbedjHjUWTlaB1tSLWEiIqiWIHkxnYk+DFXVSmdVy MqXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4si4436016plp.404.2019.05.24.07.55.29; Fri, 24 May 2019 07:55:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404144AbfEXOwg (ORCPT + 99 others); Fri, 24 May 2019 10:52:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:52908 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2403860AbfEXOwg (ORCPT ); Fri, 24 May 2019 10:52:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E02AFAF7F; Fri, 24 May 2019 14:52:34 +0000 (UTC) From: Nicolas Saenz Julienne To: Mathias Nyman Cc: oneukum@suse.com, Nicolas Saenz Julienne , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] xhci: clear port_remote_wakeup after resume failure Date: Fri, 24 May 2019 16:52:30 +0200 Message-Id: <20190524145231.6605-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This was seen on a Dell Precision 5520 using it's WD15 dock. The dock's Ethernet device interfaces with the laptop through one of it's USB3 ports. While idle, the Ethernet device and HCD are suspended by runtime PM, being the only device connected on the bus. Then, both are resumed on behalf of the Ethernet device, which has remote wake-up capabilities. The Ethernet device was observed to randomly disconnect from the USB port shortly after submitting it's remote wake-up request. Probably a weird timing issue yet to be investigated. This causes runtime PM to busyloop causing some tangible CPU load. The reason is the port gets stuck in the middle of a remote wake-up operation, waiting for the device to switch to U0. This never happens, leaving "port_remote_wakeup" enabled, and automatically triggering a failure on any further suspend operation. This patch clears "port_remote_wakeup" upon detecting a device with a wrong resuming port state (see Table 4-9 in 4.15.2.3). Making sure the above mentioned situation doesn't trigger a PM busyloop. Signed-off-by: Nicolas Saenz Julienne --- drivers/usb/host/xhci-hub.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 3abe70ff1b1e..53f5ee50ef8c 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -1047,8 +1047,8 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, xhci_get_usb2_port_status(port, &status, raw_port_status, flags); /* - * Clear stale usb2 resume signalling variables in case port changed - * state during resume signalling. For example on error + * Clear stale resume signalling variables in case port changed + * state during resume signalling. For example on error. */ if ((bus_state->resume_done[wIndex] || test_bit(wIndex, &bus_state->resuming_ports)) && @@ -1057,6 +1057,12 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, bus_state->resume_done[wIndex] = 0; clear_bit(wIndex, &bus_state->resuming_ports); usb_hcd_end_port_resume(&hcd->self, wIndex); + } else if (bus_state->port_remote_wakeup & (1 << port->hcd_portnum) && + ((raw_port_status & PORT_PLS_MASK) != XDEV_RESUME || + !(raw_port_status & PORT_CONNECT) || + !(raw_port_status & PORT_PE) || + raw_port_status & PORT_OC)) { + bus_state->port_remote_wakeup &= ~(1 << port->hcd_portnum); } if (bus_state->port_c_suspend & (1 << wIndex)) -- 2.21.0