LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Cc: gregkh@linuxfoundation.org, <martin.blumenstingl@googlemail.com>,
	<ravisadineni@google.com>, <chunfeng.yun@mediatek.com>,
	<johan@kernel.org>, <arvind.yadav.cs@gmail.com>,
	<dtor@google.com>, <anton.bondarenko.sama@gmail.com>,
	<f.fainelli@gmail.com>, <keescook@chromium.org>,
	<mathias.nyman@linux.intel.com>, <felipe.balbi@linux.intel.com>,
	<ekorenevsky@gmail.com>, <peter.chen@nxp.com>, <joe@perches.com>,
	<tbroch@google.com>, <linux-usb@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <rajatja@google.com>,
	<bleung@google.com>
Subject: Re: [PATCH] USB: Increment wakeup count on remote wakeup.
Date: Thu, 19 Apr 2018 11:01:19 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1804191053410.1288-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <20180419001850.133110-1-ravisadineni@chromium.org>

On Wed, 18 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: ravisadineni@chromium.org
> ---
>  drivers/usb/core/hcd.c |  1 +
>  drivers/usb/core/hub.c | 12 ++++++++++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 777036ae63674..79f95a878fb6e 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -2375,6 +2375,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
>  {
>  	unsigned long flags;
>  
> +	pm_wakeup_event(dev, 0);

Instead of dev, you probably want to use hcd->self.sysdev.  Or maybe
hcd->self.controller, although the difference probably doesn't matter 
for your purposes.

On the other hand, this wakeup event may already have been counted by
the host controller's bus subsystem.  Does it matter if the same wakeup
event gets counted twice?

(This is inevitable with USB devices, in any case.  If a device sends a 
wakeup request, it will be counted for that device, for all the 
intermediate hubs, and for the host controller.)

> @@ -3432,10 +3437,13 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
>  
>  	usb_lock_port(port_dev);
>  
> -	/* 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))
> +	/* Skip the initial Clear-Suspend step for a remote wakeup */

What is the reason for moving the comment line down after the 
hub_port_status() call?

Alan Stern

> +	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))
> 


  parent reply	other threads:[~2018-04-19 15:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19  0:18 Ravi Chandra Sadineni
2018-04-19  9:30 ` kbuild test robot
2018-04-19  9:33 ` kbuild test robot
2018-04-19 15:01 ` Alan Stern [this message]
2018-04-19 16:17   ` Rajat Jain
2018-04-20  0:27   ` [PATCH V2] " Ravi Chandra Sadineni
2018-04-20 14:12     ` Alan Stern
2018-04-20 17:05       ` [PATCH V3] " Ravi Chandra Sadineni
2018-04-20 17:29         ` Alan Stern
2018-04-20 17:54           ` [PATCH V4] " Ravi Chandra Sadineni
2018-04-20 18:08           ` [PATCH V5] " Ravi Chandra Sadineni
2018-04-20 18:22             ` Alan Stern
2018-04-21  8:59             ` Greg KH
2018-04-21 13:37               ` Ravi Chandra Sadineni
2018-04-20 18:12           ` [PATCH V3] " Ravi Chandra Sadineni
2018-04-20 17:07       ` [PATCH V2] " Ravi Chandra Sadineni
2018-04-20  0:50   ` [PATCH] " 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=Pine.LNX.4.44L0.1804191053410.1288-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --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=ravisadineni@google.com \
    --cc=tbroch@google.com \
    --subject='Re: [PATCH] USB: Increment wakeup count on remote wakeup.' \
    /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: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).