From: Ravi Chandra Sadineni <ravisadineni@google.com> To: Alan Stern <stern@rowland.harvard.edu> Cc: Ravi Chandra Sadineni <ravisadineni@chromium.org>, gregkh@linuxfoundation.org, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, chunfeng.yun@mediatek.com, johan@kernel.org, Arvind Yadav <arvind.yadav.cs@gmail.com>, Dmitry Torokhov <dtor@google.com>, Anton Bondarenko <anton.bondarenko.sama@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Kees Cook <keescook@chromium.org>, mathias.nyman@linux.intel.com, felipe.balbi@linux.intel.com, Eugene Korenevsky <ekorenevsky@gmail.com>, peter.chen@nxp.com, joe@perches.com, Todd Broch <tbroch@google.com>, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rajat Jain <rajatja@google.com>, Benson Leung <bleung@google.com> Subject: Re: [PATCH V3] USB: Increment wakeup count on remote wakeup. Date: Fri, 20 Apr 2018 11:12:55 -0700 [thread overview] Message-ID: <CAOGSYL3QPu=zJJSfWuLo2bWB+AEAo53BF0TPmQCBQvQLvheLfg@mail.gmail.com> (raw) In-Reply-To: <Pine.LNX.4.44L0.1804201325430.1407-100000@iolanthe.rowland.org> On Fri, Apr 20, 2018 at 10:29 AM, Alan Stern <stern@rowland.harvard.edu> 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 <ravisadineni@chromium.org> >> --- > > 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
WARNING: multiple messages have this Message-ID (diff)
From: Ravi Chandra Sadineni <ravisadineni@google.com> To: Alan Stern <stern@rowland.harvard.edu> Cc: Ravi Chandra Sadineni <ravisadineni@chromium.org>, gregkh@linuxfoundation.org, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, chunfeng.yun@mediatek.com, johan@kernel.org, Arvind Yadav <arvind.yadav.cs@gmail.com>, Dmitry Torokhov <dtor@google.com>, Anton Bondarenko <anton.bondarenko.sama@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Kees Cook <keescook@chromium.org>, mathias.nyman@linux.intel.com, felipe.balbi@linux.intel.com, Eugene Korenevsky <ekorenevsky@gmail.com>, peter.chen@nxp.com, joe@perches.com, Todd Broch <tbroch@google.com>, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rajat Jain <rajatja@google.com>, Benson Leung <bleung@google.com> Subject: [V3] USB: Increment wakeup count on remote wakeup. Date: Fri, 20 Apr 2018 11:12:55 -0700 [thread overview] Message-ID: <CAOGSYL3QPu=zJJSfWuLo2bWB+AEAo53BF0TPmQCBQvQLvheLfg@mail.gmail.com> (raw) On Fri, Apr 20, 2018 at 10:29 AM, Alan Stern <stern@rowland.harvard.edu> 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 <ravisadineni@chromium.org> >> --- > > 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 --- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-04-20 18:13 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-19 0:18 [PATCH] USB: Increment wakeup count on remote wakeup Ravi Chandra Sadineni 2018-04-19 0:18 ` Ravi Chandra Sadineni 2018-04-19 9:30 ` [PATCH] " kbuild test robot 2018-04-19 9:30 ` kbuild test robot 2018-04-19 9:33 ` [PATCH] " kbuild test robot 2018-04-19 9:33 ` kbuild test robot 2018-04-19 15:01 ` [PATCH] " Alan Stern 2018-04-19 15:01 ` Alan Stern 2018-04-19 16:17 ` [PATCH] " Rajat Jain 2018-04-19 16:17 ` Rajat Jain 2018-04-20 0:27 ` [PATCH V2] " Ravi Chandra Sadineni 2018-04-20 0:27 ` [V2] " Ravi Chandra Sadineni 2018-04-20 14:12 ` [PATCH V2] " Alan Stern 2018-04-20 14:12 ` [V2] " Alan Stern 2018-04-20 17:05 ` [PATCH V3] " Ravi Chandra Sadineni 2018-04-20 17:05 ` [V3] " Ravi Chandra Sadineni 2018-04-20 17:29 ` [PATCH V3] " Alan Stern 2018-04-20 17:29 ` [V3] " Alan Stern 2018-04-20 17:54 ` [PATCH V4] " Ravi Chandra Sadineni 2018-04-20 17:54 ` [V4] " Ravi Chandra Sadineni 2018-04-20 18:08 ` [PATCH V5] " Ravi Chandra Sadineni 2018-04-20 18:08 ` [V5] " Ravi Chandra Sadineni 2018-04-20 18:22 ` [PATCH V5] " Alan Stern 2018-04-20 18:22 ` [V5] " Alan Stern 2018-04-21 8:59 ` [PATCH V5] " Greg KH 2018-04-21 8:59 ` [V5] " Greg Kroah-Hartman 2018-04-21 13:37 ` [PATCH V5] " Ravi Chandra Sadineni 2018-04-21 13:37 ` [V5] " Ravi Chandra Sadineni 2018-04-20 18:12 ` Ravi Chandra Sadineni [this message] 2018-04-20 18:12 ` [V3] " Ravi Chandra Sadineni 2018-04-20 17:07 ` [PATCH V2] " Ravi Chandra Sadineni 2018-04-20 17:07 ` [V2] " Ravi Chandra Sadineni 2018-04-20 0:50 ` [PATCH] " Ravi Chandra Sadineni 2018-04-20 0:50 ` Ravi Chandra Sadineni
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAOGSYL3QPu=zJJSfWuLo2bWB+AEAo53BF0TPmQCBQvQLvheLfg@mail.gmail.com' \ --to=ravisadineni@google.com \ --cc=anton.bondarenko.sama@gmail.com \ --cc=arvind.yadav.cs@gmail.com \ --cc=bleung@google.com \ --cc=chunfeng.yun@mediatek.com \ --cc=dtor@google.com \ --cc=ekorenevsky@gmail.com \ --cc=f.fainelli@gmail.com \ --cc=felipe.balbi@linux.intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=joe@perches.com \ --cc=johan@kernel.org \ --cc=keescook@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=martin.blumenstingl@googlemail.com \ --cc=mathias.nyman@linux.intel.com \ --cc=peter.chen@nxp.com \ --cc=rajatja@google.com \ --cc=ravisadineni@chromium.org \ --cc=stern@rowland.harvard.edu \ --cc=tbroch@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.