Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp74271pxb; Wed, 14 Apr 2021 09:43:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyK5A+6gKO/4R/vEkrJFwojfrHaDTlrfYQ/y3WHomKi+gZ9v6Ha9ZcfUtD46J4bn5nwHdAC X-Received: by 2002:a17:90a:8b97:: with SMTP id z23mr4361007pjn.131.1618418609817; Wed, 14 Apr 2021 09:43:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618418609; cv=none; d=google.com; s=arc-20160816; b=s1XwkXZtrZv4U/bGXabPohUxSZLwpQrs0O33fjtDyShsn2v5Apm+txbBtkJeeaoPVB NsM8dfp9cUgnf7AYMccwH0aZ6W94p0cK3BdlA7tVxPBzVEjulbPf7sddQB9NXoGtw+Qd ocXAn2a3Z953qBftQ9zzM9BG0gSVWrQA3hxDdW7biy+mMeuoLR+21KJSqwSjXOE7fhVf GL1z83qCiNMG6o1NJ9zDHoLDymN0d+dfQCKWCJ7Zb8gGzonDNSedjeu7d4MgysAWeIGE 3Utvmbie17U9+9PwjhF50Bd0fp5wouwTraG8dwnza+jiCYhk+JG0xQexUEQNdgwE/Tj6 JFQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=j4jRSyz6VwZcF9TpyK3FT3rkd0N3krZJ4AlCjQ32Qt8=; b=ahcCl4SytKGrVm8bb6UM5LTw9yoFUqTwF1moG7HkAhh5Xye1KN63N+A45vibNExBlX cWsnB/T3cz6LBsxyRt7MsiqWF16oiTN0T5yKACERmR/Cmt53rsjbwCOgw1k68BRlo60G MozvMoAN9/eAFYBHlzzbRNTTGi4SrklaS9EODKKq0DdzGAV6KSaSdIYCKOAQNn8/I1RC dxT9eRiyogDgRX5baH7iMGdJJDqXG1fcXZsbiQejYfwv6Laud8S8FgyvJJw8N2IVTdGW eExOK8vfvHAhblbYzWrKyl3pPJbnMd0iWg3l6JmG/j+lufCBhMR7/DAWz1juKVspMuJ5 OJEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 64si10653pgf.222.2021.04.14.09.42.55; Wed, 14 Apr 2021 09:43:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348591AbhDNOc3 (ORCPT + 99 others); Wed, 14 Apr 2021 10:32:29 -0400 Received: from netrider.rowland.org ([192.131.102.5]:58121 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S231818AbhDNOc2 (ORCPT ); Wed, 14 Apr 2021 10:32:28 -0400 Received: (qmail 1494041 invoked by uid 1000); 14 Apr 2021 10:32:06 -0400 Date: Wed, 14 Apr 2021 10:32:06 -0400 From: Alan Stern To: Chris Chiu Cc: gregkh@linuxfoundation.org, m.v.b@runbox.com, hadess@hadess.net, linux-usb@vger.kernel.org, Linux Kernel Subject: Re: [PATCH] USB: Don't set USB_PORT_FEAT_SUSPEND on WD19's Realtek Hub Message-ID: <20210414143206.GA1493067@rowland.harvard.edu> References: <20210412150006.53909-1-chris.chiu@canonical.com> <20210412151205.GB1420451@rowland.harvard.edu> <20210413144416.GB1454681@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 14, 2021 at 01:07:43PM +0800, Chris Chiu wrote: > Thanks for the instructions. I can hit the same timeout problem with > runtime PM. The > fail rate seems the same as normal PM. (around 1/4 ~ 1/7) > root@:/sys/bus/usb/devices/3-4.3# echo auto > power/control > root@:/sys/bus/usb/devices/3-4.3# echo on > power/control > root@:/sys/bus/usb/devices/3-4.3# dmesg -c > [ 2789.679807] usb 3-4: kworker/7:0 timed out on ep0out len=0/0 > [ 2789.679812] usb 3-4-port3: can't suspend, status -110 > [ 2789.680078] usb 3-4.3: Failed to suspend device, error -110 Since these are random failures, occurring at a low rate, maybe it would help simply to retry the transfer that timed out. Have you tested this? > > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > > > > index 7f71218cc1e5..8478d49bba77 100644 > > > > > --- a/drivers/usb/core/hub.c > > > > > +++ b/drivers/usb/core/hub.c > > > > > @@ -3329,8 +3329,11 @@ int usb_port_suspend(struct usb_device *udev, pm_message_t msg) > > > > > * descendants is enabled for remote wakeup. > > > > > */ > > > > > else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0) > > > > > - status = set_port_feature(hub->hdev, port1, > > > > > - USB_PORT_FEAT_SUSPEND); > > > > > + if (udev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND) > > > > > > > > You should test hub->hdev->quirks, here, not udev->quirks. The quirk > > > > belongs to the Realtek hub, not to the device that's plugged into the > > > > hub. > > > > > > > > > > Thanks for pointing that out. I'll verify again and propose a V2 after > > > it's done. > > > > Another thing to consider: You shouldn't return 0 from usb_port_suspend > > if the port wasn't actually suspended. We don't want to kernel to have > > a false idea of the hardware's current state. > > > So we still need the "really_suspend=false". What if I replace it with > the following? > It's a little verbose but expressive enough. Any suggestions? > > + else if (!(hub->hdev->quirks & USB_QUIRK_NO_SET_FEAT_SUSPEND) && > + (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0)) > + status = set_port_feature(hub->hdev, port1, > + USB_PORT_FEAT_SUSPEND); > else { > really_suspend = false; > status = 0; You should do something more like this: - else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0) - status = set_port_feature(hub->hdev, port1, - USB_PORT_FEAT_SUSPEND); - else { + else if (PMSG_IS_AUTO(msg) || usb_wakeup_enabled_descendants(udev) > 0) { + if (hub->hdev->quirks & USB_QUIRK_NO_SUSPEND) + status = -EIO; + else + status = set_port_feature(hub->hdev, port1, + USB_PORT_FEAT_SUSPEND); + } else { really_suspend = false; status = 0; } But I would prefer to find a way to make port suspend actually work, instead of giving up on it. Alan Stern