Received: by 10.192.165.148 with SMTP id m20csp562444imm; Fri, 20 Apr 2018 11:14:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx48fxG5IdJ5GbjcJ9c/MkLoW9ybRUu0YQMPxsaIfhQCuV83K99ci3cS5iswdLOu6IdsMW/Xt X-Received: by 10.99.56.8 with SMTP id f8mr9423567pga.374.1524248081126; Fri, 20 Apr 2018 11:14:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524248081; cv=none; d=google.com; s=arc-20160816; b=xCrCn/6SGzWcJAud+pKZjYbkWpOXmM0eBcYawkxEO5BEOihEUjabSN4TVrp4ULTpt7 Q7FYD8+MGoEdncYPXeHckaA1zeewhaEuZzRBphunMDQsIoTkFkg612QCzZsWvqK7hWi2 W2Dd5MDvZr9yQCsSREZu07UH00hPeY4WurXaKa8X3+WoQU/+bCnnxxo1xK3gRj6y1Ada LmycO36DLusD9ANYshC7cGVIvp/tGUKWVTuDFAn06JJ6vd2p0PEDz+VrQlDx2TD37AH2 0eKIwJidM5gKoMeEJr+VkaiS2rNI+rHrPk9fh7qqvNwppUGsPcHdBkYwR2GSc/YeSw/8 54AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=9GuzSpBYbaSnfUnC92wOyQ2nH2xDZc1NpVhZWJxIZzs=; b=VM7MadMFAxceBaN+JMC41KU6ONkLsezylUWhhvBgzCp3iCBdoGEhNiWCGTI714Vx/6 NVB6+KO2vDn3h++v4fESqsx7qH/u37K9fdVv9aO0D19cKqbJCzyKtKshjT78E8bXgomX UqtgRrBJnDj5G+MzX5qTdUJo+0J9+kxtbF5AY+ydx2/9eeZ4OsQZmkmlF+ExrSCye1O4 a2TLcsY2bIT4b03rR8MgIYaMF7UdbVXuhbMFc0/QWKLNQrxXk8CKMM+nAUs//vPfiV/Q FF6nlNhheUSNyyu9B76X2tjL0QubbfBmX2MWSrPhavLDQmqEpmbKWLRQPgxwvKygDa4C ky9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=TDuWvwny; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si6185388pls.491.2018.04.20.11.14.26; Fri, 20 Apr 2018 11:14:41 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=TDuWvwny; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753602AbeDTSNS (ORCPT + 99 others); Fri, 20 Apr 2018 14:13:18 -0400 Received: from mail-ua0-f195.google.com ([209.85.217.195]:42033 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753158AbeDTSNR (ORCPT ); Fri, 20 Apr 2018 14:13:17 -0400 Received: by mail-ua0-f195.google.com with SMTP id f3so720506uan.9 for ; Fri, 20 Apr 2018 11:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9GuzSpBYbaSnfUnC92wOyQ2nH2xDZc1NpVhZWJxIZzs=; b=TDuWvwnyD2y+vlAJ8bCoGuM8+YN7Lu6u4U3ZMQewmZ0I2j0x8yQ5Cp/noQXML8P68j Oler+WYxA8LTJLrubKfsR2wHcBimfWCnMXjDnA7AkrAedCazboBsYysmkgqhte002xkj IUA/ZVp5mEG5cme05SCU7MKMS96zO4oXxnVPxrofHTUI53KRCR4x+iBQTnH++9jS2ACl jvUWrYE8MThlV8XJ8oTP4eoPDSyG8bwwKvcmw6UFBbqycrLPZYuMZHOZnRFTQJEQVNKZ U5TQxFsB2gn/uwqrdZl2ch8coOH7JglQxpBvGVXKxLc2AyCBmyUCB699e2k6xojla2Kf CnOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9GuzSpBYbaSnfUnC92wOyQ2nH2xDZc1NpVhZWJxIZzs=; b=Rs6S21+reZG99m5tCagyqIR4tfq4gVvyFhHVUGv+6v6YBm65GTyAYgLG7fTkQPshVT PfGRq7cUHO4QtsrLGjAvL51O0GOyNfexVDgIVGmGBKL/gvm6yu3lQBxEnzuvSYRsA5QI 2Ze5pgvqpUJc/3OeM5PsOHLwjsbMO+a8P3aoXFU/uu8Jn6UMm4HhZwi7OwDbczqXS8Ye W7pxjfphfrgx6TBx3t99MHGn9GhQhtG+bsBCAt5uN7Hl9V4cElBuM3CVV/ba5FKFRrKP jgXWpzccNtzVnV83MvurTIcxm+ioYPnsk/pe7XEn4RHYE8Bi/zbx2KPWscYrR++iYGTc B0bg== X-Gm-Message-State: ALQs6tCgZISA3lyaPHh04xCo+rO8ginRkr6in46VmlI5Kk+kAGaiduNd wEbfxSztgK9dcO8hzibbxYvK8iHFrYqKIqvvyzKHOw== X-Received: by 10.159.32.81 with SMTP id 75mr8845095uam.53.1524247995738; Fri, 20 Apr 2018 11:13:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.116.199 with HTTP; Fri, 20 Apr 2018 11:12:55 -0700 (PDT) In-Reply-To: References: <20180420170527.143240-1-ravisadineni@chromium.org> From: Ravi Chandra Sadineni Date: Fri, 20 Apr 2018 11:12:55 -0700 Message-ID: Subject: Re: [PATCH V3] USB: Increment wakeup count on remote wakeup. To: Alan Stern Cc: Ravi Chandra Sadineni , gregkh@linuxfoundation.org, Martin Blumenstingl , chunfeng.yun@mediatek.com, johan@kernel.org, Arvind Yadav , Dmitry Torokhov , Anton Bondarenko , Florian Fainelli , Kees Cook , mathias.nyman@linux.intel.com, felipe.balbi@linux.intel.com, Eugene Korenevsky , peter.chen@nxp.com, joe@perches.com, Todd Broch , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rajat Jain , Benson Leung Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2018 at 10:29 AM, Alan Stern wrote: > On Fri, 20 Apr 2018, Ravi Chandra Sadineni wrote: > >> On chromebooks we depend on wakeup count to identify the wakeup source. >> But currently USB devices do not increment the wakeup count when they >> trigger the remote wake. This patch addresses the same. >> >> Resume condition is reported differently on USB 2.0 and USB 3.0 devices. >> >> On USB 2.0 devices, a wake capable device, if wake enabled, drives >> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7). >> The upstream facing port then sets C_PORT_SUSPEND bit and reports a >> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port >> has resumed before driving the resume signal from the host and >> C_PORT_SUSPEND is set, then the device attached to the given port might >> be the reason for the last system wakeup. Increment the wakeup count for >> the same. >> >> On USB 3.0 devices, a function may signal that it wants to exit from device >> suspend by sending a Function Wake Device Notification to the host (USB3.0 >> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the >> wakeup count. >> >> Signed-off-by: Ravi Chandra Sadineni >> --- > > At this point you're supposed to list the differences between this > patch and the preceding versions. Mentioned the changes between different versions in V5. Thanks. > >> drivers/usb/core/hcd.c | 2 ++ >> drivers/usb/core/hub.c | 10 +++++++++- >> 2 files changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c >> index 777036ae63674..b8024ae4fdcaa 100644 >> --- a/drivers/usb/core/hcd.c >> +++ b/drivers/usb/core/hcd.c >> @@ -2375,6 +2375,8 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd) >> { >> unsigned long flags; >> >> + if (hcd->rh_registered) >> + pm_wakeup_event(&hcd->self.root_hub->dev, 0); >> spin_lock_irqsave (&hcd_root_hub_lock, flags); >> if (hcd->rh_registered) { >> set_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags); > > This isn't good enough. hcd->rh_registered can change at any time; > it is protected by the hcd_root_hub_lock spinlock. That's why I said > your code should be moved inside the existing "if" statement. Sorry about this. Fixed it now. Hope this is fine. Thanks. > > Alan Stern > >> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >> index f6ea16e9f6bb9..aa9968d90a48c 100644 >> --- a/drivers/usb/core/hub.c >> +++ b/drivers/usb/core/hub.c >> @@ -653,12 +653,17 @@ void usb_wakeup_notification(struct usb_device *hdev, >> unsigned int portnum) >> { >> struct usb_hub *hub; >> + struct usb_port *port_dev; >> >> if (!hdev) >> return; >> >> hub = usb_hub_to_struct_hub(hdev); >> if (hub) { >> + port_dev = hub->ports[portnum - 1]; >> + if (port_dev && port_dev->child) >> + pm_wakeup_event(&port_dev->child->dev, 0); >> + >> set_bit(portnum, hub->wakeup_bits); >> kick_hub_wq(hub); >> } >> @@ -3434,8 +3439,11 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg) >> >> /* Skip the initial Clear-Suspend step for a remote wakeup */ >> status = hub_port_status(hub, port1, &portstatus, &portchange); >> - if (status == 0 && !port_is_suspended(hub, portstatus)) >> + if (status == 0 && !port_is_suspended(hub, portstatus)) { >> + if (portchange & USB_PORT_STAT_C_SUSPEND) >> + pm_wakeup_event(&udev->dev, 0); >> goto SuspendCleared; >> + } >> >> /* see 7.1.7.7; affects power usage, but not budgeting */ >> if (hub_is_superspeed(hub->hdev)) >> > Thanks, Ravi