linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Guan-Yu Lin <guanyulin@google.com>
Cc: mathias.nyman@intel.com, stern@rowland.harvard.edu,
	sumit.garg@kernel.org, gargaditya08@live.com, kekrby@gmail.com,
	jeff.johnson@oss.qualcomm.com, quic_zijuhu@quicinc.com,
	andriy.shevchenko@linux.intel.com, ben@decadent.org.uk,
	broonie@kernel.org, quic_wcheng@quicinc.com,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v12 2/4] usb: add apis for offload usage tracking
Date: Fri, 25 Apr 2025 13:12:47 +0200	[thread overview]
Message-ID: <2025042540-implode-yelp-b8e5@gregkh> (raw)
In-Reply-To: <20250416144917.16822-3-guanyulin@google.com>

On Wed, Apr 16, 2025 at 02:43:02PM +0000, Guan-Yu Lin wrote:
> Introduce offload_usage and corresponding apis to track offload usage
> on each USB device. Offload denotes that there is another co-processor
> accessing the USB device via the same USB host controller. To optimize
> power usage, it's essential to monitor whether the USB device is
> actively used by other co-processor. This information is vital when
> determining if a USB device can be safely suspended during system power
> state transitions.
> 
> Signed-off-by: Guan-Yu Lin <guanyulin@google.com>
> ---
>  drivers/usb/core/driver.c | 109 ++++++++++++++++++++++++++++++++++++++
>  drivers/usb/core/usb.c    |   1 +
>  drivers/usb/host/Kconfig  |  11 ++++
>  include/linux/usb.h       |  17 ++++++
>  4 files changed, 138 insertions(+)
> 
> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> index 460d4dde5994..76372690add0 100644
> --- a/drivers/usb/core/driver.c
> +++ b/drivers/usb/core/driver.c
> @@ -2036,6 +2036,115 @@ int usb_disable_usb2_hardware_lpm(struct usb_device *udev)
>  
>  #endif /* CONFIG_PM */
>  
> +#if IS_ENABLED(CONFIG_USB_XHCI_SIDEBAND_SUSPEND)
> +
> +/**
> + * usb_offload_get - increment the offload_usage of a USB device
> + * @udev: the USB device to increment its offload_usage
> + *
> + * Incrementing the offload_usage of a usb_device indicates that offload is
> + * enabled on this usb_device; that is, another entity is actively handling USB
> + * transfers. This information allows the USB driver to adjust its power
> + * management policy based on offload activity.
> + *
> + * The caller must hold @udev's device lock.
> + *
> + * Return: 0 on success. A negative error code otherwise.
> + */
> +int usb_offload_get(struct usb_device *udev)
> +{
> +	int ret;
> +
> +	if (udev->state == USB_STATE_NOTATTACHED ||
> +			udev->state == USB_STATE_SUSPENDED)
> +		return -EAGAIN;
> +
> +	/*
> +	 * offload_usage could only be modified when the device is active, since
> +	 * it will alter the suspend flow of the device.
> +	 */
> +	ret = usb_autoresume_device(udev);
> +
> +	if (ret < 0)
> +		return ret;
> +
> +	udev->offload_usage++;
> +	usb_autosuspend_device(udev);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_offload_get);
> +
> +/**
> + * usb_offload_put - drop the offload_usage of a USB device
> + * @udev: the USB device to drop its offload_usage
> + *
> + * The inverse operation of usb_offload_get, which drops the offload_usage of
> + * a USB device. This information allows the USB driver to adjust its power
> + * management policy based on offload activity.
> + *
> + * The caller must hold @udev's device lock.
> + *
> + * Return: 0 on success. A negative error code otherwise.
> + */
> +int usb_offload_put(struct usb_device *udev)
> +{
> +	int ret;
> +
> +	if (udev->state == USB_STATE_NOTATTACHED ||
> +			udev->state == USB_STATE_SUSPENDED)
> +		return -EAGAIN;

What's to prevent the state of the device from changing right after you
check for this?

And why -EAGAIN, you don't mention that in the comment for the function.

Also, to pile on, sorry, the coding style needs to be fixed up here :)

> +
> +	/*
> +	 * offload_usage could only be modified when the device is active, since
> +	 * it will alter the suspend flow of the device.
> +	 */
> +	ret = usb_autoresume_device(udev);
> +
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Drop the count when it wasn't 0, ignore the operation otherwise. */
> +	if (udev->offload_usage)
> +		udev->offload_usage--;
> +	usb_autosuspend_device(udev);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_offload_put);
> +
> +/**
> + * usb_offload_check - check offload activities on a USB device
> + * @udev: the USB device to check its offload activity.
> + *
> + * Check if there are any offload activity on the USB device right now. This
> + * information could be used for power management or other forms of resource
> + * management.
> + *
> + * The caller must hold @udev's device lock.
> + *
> + * Returns true on any offload activity, false otherwise.
> + */
> +bool usb_offload_check(struct usb_device *udev)
> +{
> +	struct usb_device *child;
> +	bool active;
> +	int port1;
> +
> +	usb_hub_for_each_child(udev, port1, child) {

No locking is needed for this loop at all?  What happens if a device is
added or removed while it is looping?

> +		device_lock(&child->dev);
> +		active = usb_offload_check(child);
> +		device_unlock(&child->dev);
> +		if (active)
> +			return true;
> +	}
> +
> +	return !!udev->offload_usage;

But the state can change right afterwards, so no one can do anything
with this value, right?  What is is used for?

thanks,

greg k-h

  reply	other threads:[~2025-04-25 11:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 14:43 [PATCH v12 0/4] Support system sleep with offloaded usb transfers Guan-Yu Lin
2025-04-16 14:43 ` [PATCH v12 1/4] usb: xhci-plat: separate dev_pm_ops for each pm_event Guan-Yu Lin
2025-04-16 14:43 ` [PATCH v12 2/4] usb: add apis for offload usage tracking Guan-Yu Lin
2025-04-25 11:12   ` Greg KH [this message]
2025-05-16  4:45     ` Guan-Yu Lin
2025-04-16 14:43 ` [PATCH v12 3/4] xhci: sideband: add api to trace sideband usage Guan-Yu Lin
2025-04-25 11:14   ` Greg KH
2025-05-15 11:28     ` Guan-Yu Lin
2025-04-16 14:43 ` [PATCH v12 4/4] usb: host: enable USB offload during system sleep Guan-Yu Lin
2025-04-25 11:15   ` Greg KH
2025-05-15 10:37     ` Guan-Yu Lin

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=2025042540-implode-yelp-b8e5@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ben@decadent.org.uk \
    --cc=broonie@kernel.org \
    --cc=gargaditya08@live.com \
    --cc=guanyulin@google.com \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=kekrby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=quic_wcheng@quicinc.com \
    --cc=quic_zijuhu@quicinc.com \
    --cc=stern@rowland.harvard.edu \
    --cc=sumit.garg@kernel.org \
    /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 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).