Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5999572ybl; Sun, 22 Dec 2019 20:33:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwEfSeFPJNzvDBNyw5y7msYBEA1UMmZyxysiIVtpPaQ3Kb5fZu4S4s8G5UX0CfunRLn2ZIo X-Received: by 2002:a9d:68cb:: with SMTP id i11mr26944509oto.210.1577075635791; Sun, 22 Dec 2019 20:33:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577075635; cv=none; d=google.com; s=arc-20160816; b=DAj/93Fc9vdRqUzIGnFQahcMxOxwueIhjNHg4p3xFc4fVH1IcWP59/7/BW0CIKtZ+8 zzi25eu+9Y9n/RIoTir9Q9QB45MPY3ptCa3L5TgZ6Ab/xA/5Keef+Li8f2ti1Li0Cvj5 Qj7RKuomUNoHiYBX0TOr1WqfzXyRGeblWHlhnSbZzs5uJMHGhLvymXhDzLu4NNU8zXLV XxfH6td4t6oiPm7ITOSQEZOel0MjzRX9O579F4KvuNXZA31z4HTQ5e9EPRZ3jWDAl+8U P1AMR5m/L8XRh50MGMX8NxaTadRDmTa9WX35vr1mQh2LgdEjN0P1THm5R19GSUmBRGw3 E2FA== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=eZ2KRdt5ozISKFY0tlmawEqAThRDjNUizJRQTGNuxDo=; b=jgFH0fLrmf5XQtA1bnNtUhYTPEi2Avtt+gFi2FQ2H+0MoSjUbeNQ2EWQnB77B/Uhfy YMC9oshIFmRf6040prI2S4kyE0VkSHOsNFp2KCzXAalNxcpfRiggEX5Qm8wHPw9NcrAH it/SVjux1dUIsyF6ZWRrgWJScX6gW2f+mHE2dyGEsvlVVOkNF8EasUiZfCth9xYQSrhI r6QBZ5sJmVQMyW+KkXPXximk2tbrhgYBSTbyQ7Nug+vefS3PCBjtYTdGIwGPeDbE82y6 pNSKHtNQ1at05j6LWnUl4rrYNDVbuml5gke5vldTyTPbojYkNUjFehcWPPtOoDLoQXZw p1iA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b1si5171605otl.302.2019.12.22.20.33.10; Sun, 22 Dec 2019 20:33:55 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726663AbfLWE3v convert rfc822-to-8bit (ORCPT + 99 others); Sun, 22 Dec 2019 23:29:51 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:47818 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726613AbfLWE3v (ORCPT ); Sun, 22 Dec 2019 23:29:51 -0500 Received: from mail-wr1-f70.google.com ([209.85.221.70]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ijFLo-0007Pe-R3 for linux-kernel@vger.kernel.org; Mon, 23 Dec 2019 04:29:48 +0000 Received: by mail-wr1-f70.google.com with SMTP id 90so7371595wrq.6 for ; Sun, 22 Dec 2019 20:29:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dpoHWFqcQ1TpfseO0Nokc21cLrtit4YIE7VtBBHccsA=; b=JEH56UsIE4wHOcKO0UARt8wrad8pV1JJqmxaiMDtuI0dQdMrwq8lt8ICOtko6GRU74 6l6QZCHtcuCB9REos0DzR1XduI18JhtDn0mVVTeD8bnVzsFj9EE4w8eECj8SQOvM01cL GcYRn0I+qsIVNCvlnwKpHoX8GCqD6xBP7aNIZ6E4PNc/5vabzuV1I9OjUtOHYatfzVQs taRGLbKOgpPtV3dwtAXlv4Oqd8BTK3FLpNCtvyrfZnqb1DfPXW4si6R2NRyAyoaHCRTG Pg1bcnkUkdPRed46kCCp9Q/QYT7GkbBxAmT/+JMpT2MPZqHy2zP3J+3XtjDAcmqjqTIm JX6w== X-Gm-Message-State: APjAAAUqW0MEAoHZ18SBoOrXcPmC6zvRbpfftWdXYcBL+HtqsEstyaBj 9IdHZuiw4tb+wfv6uei1EKFF50JC9u9UGf4pHTO8YOBPU1PCwoDonzqPD7gj0G5yZByhxmIA0mM r5bOMm/3PqVh/HUOHjAhxxkUFAq4DR+m/w8OZW/6+Pfp5dlDrt3GNspQyyw== X-Received: by 2002:a1c:80d4:: with SMTP id b203mr28533289wmd.102.1577075388553; Sun, 22 Dec 2019 20:29:48 -0800 (PST) X-Received: by 2002:a1c:80d4:: with SMTP id b203mr28533284wmd.102.1577075388321; Sun, 22 Dec 2019 20:29:48 -0800 (PST) MIME-Version: 1.0 References: <20191220025917.11886-1-acelan.kao@canonical.com> In-Reply-To: From: AceLan Kao Date: Mon, 23 Dec 2019 12:29:37 +0800 Message-ID: Subject: Re: [PATCH] usb: hub: move resume delay at the head of all USB access functions To: Alan Stern Cc: Greg Kroah-Hartman , Kai-Heng Feng , Thinh Nguyen , Harry Pan , David Heinzelmann , Andrey Konovalov , Nicolas Saenz Julienne , Mathieu Malaterre , linux-usb@vger.kernel.org, "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alan Stern 於 2019年12月20日 週五 下午11:48寫道: > > On Fri, 20 Dec 2019, AceLan Kao wrote: > > > usb_control_msg() function should be called after the resume delay, or > > Which usb_control_msg() call are you referring to? Is it the call > under hub_port_status()? usb_port_resume() -> hub_port_status() -> hub_ext_port_status() -> get_port_status() -> usb_control_msg() > > > you'll encounter the below errors sometime. > > After the issue happens, have to re-plug the USB cable to recover. > > > > [ 837.483573] hub 2-3:1.0: hub_ext_port_status failed (err = -71) > > [ 837.490889] hub 2-3:1.0: hub_ext_port_status failed (err = -71) > > [ 837.506780] usb 2-3-port4: cannot disable (err = -71) > > You need to do a better job of figuring out why these errors occur. It > is not connected to the resume delay; there must be a different reason. > Hint: This is the sort of error you would expect to see if the kernel > tried to resume a device while its parent hub was still suspended. Once this error shows, the USB port doesn't work until re-plug the cable. I have no idea what else I can do to this, do you have any idea that I could try? Thanks. > > > Signed-off-by: AceLan Kao > > --- > > drivers/usb/core/hub.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index f229ad6952c0..2fb2816b0d38 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -3522,6 +3522,7 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg) > > } > > } > > > > + msleep(USB_RESUME_TIMEOUT); > > This makes no sense at all. At this point we haven't even started to > do the resume signalling, so there's no reason to wait for it to > finish. I thought the h/w need some time to be back to stable status when resuming. > > > usb_lock_port(port_dev); > > > > /* Skip the initial Clear-Suspend step for a remote wakeup */ > > @@ -3544,7 +3545,6 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg) > > /* drive resume for USB_RESUME_TIMEOUT msec */ > > dev_dbg(&udev->dev, "usb %sresume\n", > > (PMSG_IS_AUTO(msg) ? "auto-" : "")); > > - msleep(USB_RESUME_TIMEOUT); > > This is wrong also. At this point the resume signal _is_ being sent, > and the USB spec requires that we wait a minimum amount of time for the > device to fully resume. I don't see the difference that after the delay, it calls hub_port_status(), but in the beginning of usb_port_resume() it call the same function, too. So, I think it should be good to move the delay before the first hub_port_status() > > Alan Stern >