All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Evan Green <evgreen@chromium.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Rajat Jain <rajatja@chromium.org>,
	Razvan Heghedus <heghedus.razvan@gmail.com>,
	Wei Ming Chen <jj251510319013@gmail.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 1/2] USB: core: Disable remote wakeup for freeze/quiesce
Date: Tue, 19 Apr 2022 10:41:21 -0400	[thread overview]
Message-ID: <Yl7KEX++hJac8T6I@rowland.harvard.edu> (raw)
In-Reply-To: <20220418135819.v2.1.I2c636c4decc358f5e6c27b810748904cc69beada@changeid>

On Mon, Apr 18, 2022 at 02:00:45PM -0700, Evan Green wrote:
> The PM_EVENT_FREEZE and PM_EVENT_QUIESCE messages should cause the
> device to stop generating interrupts. USB core was previously allowing
> devices that were already runtime suspended to keep remote wakeup
> enabled if they had gone down that way. This violates the contract with
> pm, and can potentially cause MSI interrupts to be lost.
> 
> Change that so that if a device is runtime suspended with remote wakeups
> enabled, it will be resumed to ensure remote wakeup is always disabled
> across a freeze.
> 
> Signed-off-by: Evan Green <evgreen@chromium.org>
> ---
> 
> (no changes since v1)
> 
>  drivers/usb/core/driver.c | 20 +++++++++-----------
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> index 355ed33a21792b..93c8cf66adccec 100644
> --- a/drivers/usb/core/driver.c
> +++ b/drivers/usb/core/driver.c
> @@ -1533,20 +1533,18 @@ static void choose_wakeup(struct usb_device *udev, pm_message_t msg)
>  {
>  	int	w;
>  
> -	/* Remote wakeup is needed only when we actually go to sleep.
> -	 * For things like FREEZE and QUIESCE, if the device is already
> -	 * autosuspended then its current wakeup setting is okay.
> +	/* For FREEZE/QUIESCE, disable remote wakeups so no interrupts get generated
> +	 * by the device.

You mean "by the host controller".  USB devices don't generate 
interrupts; they generate wakeup requests (which can cause a host 
controller to generate an interrupt).

>  	 */
>  	if (msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_QUIESCE) {
> -		if (udev->state != USB_STATE_SUSPENDED)
> -			udev->do_remote_wakeup = 0;
> -		return;
> -	}
> +		w = 0;
>  
> -	/* Enable remote wakeup if it is allowed, even if no interface drivers
> -	 * actually want it.
> -	 */
> -	w = device_may_wakeup(&udev->dev);
> +	} else {
> +		/* Enable remote wakeup if it is allowed, even if no interface drivers
> +		 * actually want it.
> +		 */
> +		w = device_may_wakeup(&udev->dev);
> +	}
>  
>  	/* If the device is autosuspended with the wrong wakeup setting,
>  	 * autoresume now so the setting can be changed.
> -- 

I would prefer it if you reformatted the comments to agree with the 
current style:

	/*
	 * Blah blah blah
	 */

and to avoid line wrap beyond 80 columns.  Apart from that:

Acked-by: Alan Stern <stern@rowland.harvard.edu>

Alan Stern

  reply	other threads:[~2022-04-19 14:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 21:00 [PATCH v2 0/2] USB: Quiesce interrupts across pm freeze Evan Green
2022-04-18 21:00 ` [PATCH v2 1/2] USB: core: Disable remote wakeup for freeze/quiesce Evan Green
2022-04-19 14:41   ` Alan Stern [this message]
2022-04-20 19:30     ` Evan Green
2022-04-18 21:00 ` [PATCH v2 2/2] USB: hcd-pci: Fully suspend across freeze/thaw cycle Evan Green
2022-04-19 14:43   ` Alan Stern
2022-04-19  7:05 ` [PATCH v2 0/2] USB: Quiesce interrupts across pm freeze Oliver Neukum
2022-04-19 14:35   ` Alan Stern
2022-04-19 15:51     ` Oliver Neukum
2022-04-19 17:49       ` Alan Stern
2022-04-20  8:47         ` Oliver Neukum
2022-04-20 14:09           ` Alan Stern

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=Yl7KEX++hJac8T6I@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=evgreen@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heghedus.razvan@gmail.com \
    --cc=jj251510319013@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=rajatja@chromium.org \
    --cc=tglx@linutronix.de \
    /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
Be 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.