Wesley Cheng and Mathias Nyman's USB offload design enables a co-processor
to handle some USB transfers, potentially allowing the system to sleep
(suspend-to-RAM) and save power. However, Linux's System Sleep model halts
the USB host controller when the main system isn't managing any USB
transfers. To address this, the proposal modifies the system to recognize
offloaded USB transfers and manage power accordingly. This way, offloaded
USB transfers could still happen during system sleep (Suspend-to-RAM).

This involves two key steps:
1. Transfer Status Tracking: Propose offload_usage and corresponding apis
drivers could track USB transfers on the co-processor, ensuring the
system is aware of any ongoing activity.
2. Power Management Adjustment:  Modifications to the USB driver stack
(xhci host controller driver, and USB device drivers) allow the system to
sleep (Suspend-to-RAM) without disrupting co-processor managed USB
transfers. This involves adding conditional checks to bypass some power
management operations in the System Sleep model.

changelog
----------
Changes in v14:
- Introduce CONFIG_USB_OFFLOAD for control usb offload related features.
- Specify __must_hold marco on usb_offload_check().
- Cosmetics changes on coding style.


Changes in v13:
- Ensure offload_usage is modified only when the device is neither
  suspended nor marked as "offload_at_suspend".
- Move lock manipulations into usb_offload_get()/usb_offload_put().
- Cosmetics changes on coding style.

Changes in v12:
- Rebase on TOT.
- Cosmetics changes on coding style.

Changes in v11:
- Use USB subsystem wrappers in usb_offload_get()/usb_offload_put().
- Refine logics and add comment in usb_suspend_both()/usb_resume_both().

Changes in v10:
- Remove unnecessary operations in dwc3 driver.
- Introduce CONFIG_USB_XHCI_SIDEBAND_SUSPEND to enable/disable offloaded
  usb transfers during system Suspend-to-RAM.
- Modify the approach to detect offloaded USB transfers when the system
  resumes from Suspend-to-RAM.
- Mark sideband activity when sideband interrupters are created/removed.
- Cosmetics changes on coding style.

Changes in v9:
- Remove unnecessary white space change.

Changes in v8:
- Change the runtime pm api to correct the error handling flow.
- Not flushing endpoints of actively offloaded USB devices to avoid
  possible USB transfer conflicts.

Changes in v7:
- Remove counting mechanism in struct usb_hcd. The USB device's offload
  status will be solely recorded in each related struct usb_device.
- Utilizes `needs_remote_wakeup` attribute in struct usb_interface to
  control the suspend flow of USB interfaces and associated USB endpoints.
  This addresses the need to support interrupt transfers generated by
  offloaded USB devices while the system is suspended.
- Block any offload_usage change during USB device suspend period.

Changes in v6:
- Fix build errors when CONFIG_USB_XHCI_SIDEBAND is disabled.
- Explicitly specify the data structure of the drvdata refereced in
  dwc3_suspend(), dwc3_resume().
- Move the initialization of counters to the patches introducing them.

Changes in v5:
- Walk through the USB children in usb_sideband_check() to determine the
  sideband activity under the specific USB device. 
- Replace atomic_t by refcount_t.
- Reduce logs by using dev_dbg & remove __func__.

Changes in v4:
- Isolate the feature into USB driver stack.
- Integrate with series "Introduce QC USB SND audio offloading support"

Changes in v3:
- Integrate the feature with the pm core framework.

Changes in v2:
- Cosmetics changes on coding style.

[v3] PM / core: conditionally skip system pm in device/driver model
[v2] usb: host: enable suspend-to-RAM control in userspace
[v1] [RFC] usb: host: Allow userspace to control usb suspend flows
---

Guan-Yu Lin (4):
  usb: xhci-plat: separate dev_pm_ops for each pm_event
  usb: offload: add apis for offload usage tracking
  xhci: sideband: add api to trace sideband usage
  usb: host: enable USB offload during system sleep

 drivers/usb/core/Kconfig          |  10 +++
 drivers/usb/core/Makefile         |   1 +
 drivers/usb/core/driver.c         |  50 +++++++++--
 drivers/usb/core/offload.c        | 136 ++++++++++++++++++++++++++++++
 drivers/usb/core/usb.c            |   1 +
 drivers/usb/host/Kconfig          |  11 +++
 drivers/usb/host/xhci-plat.c      |  42 ++++++++-
 drivers/usb/host/xhci-plat.h      |   1 +
 drivers/usb/host/xhci-sideband.c  |  38 +++++++++
 include/linux/usb.h               |  18 ++++
 include/linux/usb/xhci-sideband.h |   9 ++
 11 files changed, 307 insertions(+), 10 deletions(-)
 create mode 100644 drivers/usb/core/offload.c

-- 
2.49.0.1204.g71687c7c1d-goog

On Wed, Jun 04, 2025 at 08:23:06AM +0000, Guan-Yu Lin wrote:
> Wesley Cheng and Mathias Nyman's USB offload design enables a co-processor
> to handle some USB transfers, potentially allowing the system to sleep
> (suspend-to-RAM) and save power. However, Linux's System Sleep model halts
> the USB host controller when the main system isn't managing any USB
> transfers. To address this, the proposal modifies the system to recognize
> offloaded USB transfers and manage power accordingly. This way, offloaded
> USB transfers could still happen during system sleep (Suspend-to-RAM).
> 
> This involves two key steps:
> 1. Transfer Status Tracking: Propose offload_usage and corresponding apis
> drivers could track USB transfers on the co-processor, ensuring the
> system is aware of any ongoing activity.
> 2. Power Management Adjustment:  Modifications to the USB driver stack
> (xhci host controller driver, and USB device drivers) allow the system to
> sleep (Suspend-to-RAM) without disrupting co-processor managed USB
> transfers. This involves adding conditional checks to bypass some power
> management operations in the System Sleep model.

Is there a reason you aren't cc:ing the developers from a "big android
device company" that is currently testing and finding problems with this
patchset in their device testing?  I will require their signed-off-by or
tested-by in order to even consider accepting this patch series based on
the issues they seem to be finding with it in an
internal-company-bug-reporting-platform that I seem to be also copied
on.

thanks,

greg k-h

On Wed, Jun 4, 2025 at 6:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jun 04, 2025 at 08:23:06AM +0000, Guan-Yu Lin wrote:
>
> Is there a reason you aren't cc:ing the developers from a "big android
> device company" that is currently testing and finding problems with this
> patchset in their device testing?  I will require their signed-off-by or
> tested-by in order to even consider accepting this patch series based on
> the issues they seem to be finding with it in an
> internal-company-bug-reporting-platform that I seem to be also copied
> on.
>
> thanks,
>
> greg k-h

I'm not sure if the company wants to reveal its testing right now
since the company raised the problem with the internal system. Hence,
we still use the internal system to communicate with them. We
understand that "signed-off-by"/"tested-by" tags are required to merge
the code, so we'll keep working closely with multiple companies to
achieve this.

Regards,
Guan-Yu

On Wed, Jun 04, 2025 at 08:32:00PM +0800, Guan-Yu Lin wrote:
> On Wed, Jun 4, 2025 at 6:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jun 04, 2025 at 08:23:06AM +0000, Guan-Yu Lin wrote:
> >
> > Is there a reason you aren't cc:ing the developers from a "big android
> > device company" that is currently testing and finding problems with this
> > patchset in their device testing?  I will require their signed-off-by or
> > tested-by in order to even consider accepting this patch series based on
> > the issues they seem to be finding with it in an
> > internal-company-bug-reporting-platform that I seem to be also copied
> > on.
> >
> > thanks,
> >
> > greg k-h
> 
> I'm not sure if the company wants to reveal its testing right now
> since the company raised the problem with the internal system. Hence,
> we still use the internal system to communicate with them. We
> understand that "signed-off-by"/"tested-by" tags are required to merge
> the code, so we'll keep working closely with multiple companies to
> achieve this.

Great, please do so for the next version you post.

thanks,

greg k-h

On Thu, Jun 19, 2025 at 5:27 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jun 04, 2025 at 08:32:00PM +0800, Guan-Yu Lin wrote:
> > On Wed, Jun 4, 2025 at 6:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jun 04, 2025 at 08:23:06AM +0000, Guan-Yu Lin wrote:
> > >
> > > Is there a reason you aren't cc:ing the developers from a "big android
> > > device company" that is currently testing and finding problems with this
> > > patchset in their device testing?  I will require their signed-off-by or
> > > tested-by in order to even consider accepting this patch series based on
> > > the issues they seem to be finding with it in an
> > > internal-company-bug-reporting-platform that I seem to be also copied
> > > on.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I'm not sure if the company wants to reveal its testing right now
> > since the company raised the problem with the internal system. Hence,
> > we still use the internal system to communicate with them. We
> > understand that "signed-off-by"/"tested-by" tags are required to merge
> > the code, so we'll keep working closely with multiple companies to
> > achieve this.
>
> Great, please do so for the next version you post.
>
> thanks,
>
> greg k-h

Hi Wesley,

Right now the system sleep with offloaded usb transfers feature is
pretty much settled. I was wondering if you could test the patch on
your platform? Thanks!

Regards,
Guan-Yu

On Tue, Jul 1, 2025 at 11:05 PM Guan-Yu Lin <guanyulin@google.com> wrote:
>
> On Thu, Jun 19, 2025 at 5:27 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Jun 04, 2025 at 08:32:00PM +0800, Guan-Yu Lin wrote:
> > > On Wed, Jun 4, 2025 at 6:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, Jun 04, 2025 at 08:23:06AM +0000, Guan-Yu Lin wrote:
> > > >
> > > > Is there a reason you aren't cc:ing the developers from a "big android
> > > > device company" that is currently testing and finding problems with this
> > > > patchset in their device testing?  I will require their signed-off-by or
> > > > tested-by in order to even consider accepting this patch series based on
> > > > the issues they seem to be finding with it in an
> > > > internal-company-bug-reporting-platform that I seem to be also copied
> > > > on.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > I'm not sure if the company wants to reveal its testing right now
> > > since the company raised the problem with the internal system. Hence,
> > > we still use the internal system to communicate with them. We
> > > understand that "signed-off-by"/"tested-by" tags are required to merge
> > > the code, so we'll keep working closely with multiple companies to
> > > achieve this.
> >
> > Great, please do so for the next version you post.
> >
> > thanks,
> >
> > greg k-h
>
> Hi Wesley,
>
> Right now the system sleep with offloaded usb transfers feature is
> pretty much settled. I was wondering if you could test the patch on
> your platform? Thanks!
>
> Regards,
> Guan-Yu

Hi Jung,

I noticed that you've adapted the latest sideband design for audio
offload in your system. I was wondering if you could adapt this
patchset as well to further enable offloaded usb transfers during
system suspend? Thanks!

Regards,
Guan-Yu

On Wed, Jul 02, 2025 at 12:33:00PM +0800, Guan-Yu Lin wrote:
> On Tue, Jul 1, 2025 at 11:05 PM Guan-Yu Lin <guanyulin@google.com> wrote:
> >
> > On Thu, Jun 19, 2025 at 5:27 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Wed, Jun 04, 2025 at 08:32:00PM +0800, Guan-Yu Lin wrote:
> > > > On Wed, Jun 4, 2025 at 6:56 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Wed, Jun 04, 2025 at 08:23:06AM +0000, Guan-Yu Lin wrote:
> > > > >
> > > > > Is there a reason you aren't cc:ing the developers from a "big android
> > > > > device company" that is currently testing and finding problems with this
> > > > > patchset in their device testing?  I will require their signed-off-by or
> > > > > tested-by in order to even consider accepting this patch series based on
> > > > > the issues they seem to be finding with it in an
> > > > > internal-company-bug-reporting-platform that I seem to be also copied
> > > > > on.
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > I'm not sure if the company wants to reveal its testing right now
> > > > since the company raised the problem with the internal system. Hence,
> > > > we still use the internal system to communicate with them. We
> > > > understand that "signed-off-by"/"tested-by" tags are required to merge
> > > > the code, so we'll keep working closely with multiple companies to
> > > > achieve this.
> > >
> > > Great, please do so for the next version you post.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Wesley,
> >
> > Right now the system sleep with offloaded usb transfers feature is
> > pretty much settled. I was wondering if you could test the patch on
> > your platform? Thanks!
> >
> > Regards,
> > Guan-Yu
> 
> Hi Jung,
> 
> I noticed that you've adapted the latest sideband design for audio
> offload in your system. I was wondering if you could adapt this
> patchset as well to further enable offloaded usb transfers during
> system suspend? Thanks!
> 
> Regards,
> Guan-Yu
> 

Hi Guan,

We can't adapt this patchset on Exynos platform now. My co-worker currently
analyzing it, and it might take some time.

Best Regards,
Daehwan Jung