[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2025052808-shown-sitting-1ff9@gregkh>
Date: Wed, 28 May 2025 11:14:58 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Guan-Yu Lin <guanyulin@...gle.com>
Cc: mathias.nyman@...el.com, gargaditya08@...e.com, kekrby@...il.com,
jeff.johnson@....qualcomm.com, quic_zijuhu@...cinc.com,
andriy.shevchenko@...ux.intel.com, ben@...adent.org.uk,
broonie@...nel.org, quic_wcheng@...cinc.com,
krzysztof.kozlowski@...aro.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v13 2/4] usb: add apis for offload usage tracking
On Wed, May 28, 2025 at 09:04:07AM +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@...gle.com>
> ---
> drivers/usb/core/driver.c | 125 ++++++++++++++++++++++++++++++++++++++
> drivers/usb/core/usb.c | 1 +
> drivers/usb/host/Kconfig | 11 ++++
> include/linux/usb.h | 18 ++++++
> 4 files changed, 155 insertions(+)
>
> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
> index 460d4dde5994..0690619454fe 100644
> --- a/drivers/usb/core/driver.c
> +++ b/drivers/usb/core/driver.c
> @@ -2036,6 +2036,131 @@ int usb_disable_usb2_hardware_lpm(struct usb_device *udev)
>
> #endif /* CONFIG_PM */
>
> +#if IS_ENABLED(CONFIG_USB_XHCI_SIDEBAND_SUSPEND)
ifdef in .c files are messy and hard to maintain.
Also, why is an xhci-specific option enabling/disabling core USB
functions like this? Shouldn't it be a generic USB config option name
instead?
> +
> +/**
> + * 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.
> + *
> + * Return: 0 on success. A negative error code otherwise.
> + */
> +int usb_offload_get(struct usb_device *udev)
> +{
> + int ret;
> +
> + usb_lock_device(udev);
> + if (udev->state == USB_STATE_NOTATTACHED) {
> + ret = -ENODEV;
> + goto unlock_device;
Shouldn't we using the guard logic here instead? That would make all of
this look much simpler and easier to maintain over time.
> + } else if (udev->state == USB_STATE_SUSPENDED ||
> + udev->offload_at_suspend) {
> + ret = -EBUSY;
> + goto unlock_device;
> + }
> +
> + /*
> + * 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)
Why the blank line?
> + goto unlock_device;
> +
> + udev->offload_usage++;
> + usb_autosuspend_device(udev);
> +
> +unlock_device:
> + usb_unlock_device(udev);
> +
> + return ret;
> +}
> +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.
> + *
> + * Return: 0 on success. A negative error code otherwise.
> + */
> +int usb_offload_put(struct usb_device *udev)
> +{
> + int ret;
> +
> + usb_lock_device(udev);
> + if (udev->state == USB_STATE_NOTATTACHED) {
> + ret = -ENODEV;
> + goto unlock_device;
> + } else if (udev->state == USB_STATE_SUSPENDED ||
> + udev->offload_at_suspend) {
> + ret = -EBUSY;
> + goto unlock_device;
> + }
> +
> + /*
> + * 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)
> + goto unlock_device;
> +
> + /* Drop the count when it wasn't 0, ignore the operation otherwise. */
> + if (udev->offload_usage)
> + udev->offload_usage--;
> + usb_autosuspend_device(udev);
> +
> +unlock_device:
> + usb_unlock_device(udev);
> +
> + return ret;
> +}
> +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. In addition, the caller should
> + * ensure downstream usb devices are all either suspended or marked as
> + * "offload_at_suspend" to ensure the correctness of the return value.
> + *
> + * 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) {
> + usb_lock_device(child);
> + active = usb_offload_check(child);
> + usb_unlock_device(child);
> + if (active)
> + return true;
> + }
> +
> + return !!udev->offload_usage;
I think you forgot to mark this function as requiring that the lock be
held, right? Just documenting it isn't going to be simple to notice or
maintain over time...
thanks,
greg k-h
Powered by blists - more mailing lists