linux-kernel - Re: [PATCH v7 5/5] usb: host: enable USB offload during system sleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOuDEK0jNn-nSb7Rk_0EYtFg+Mxybij6cGnOenq4FPJdTKyjng@mail.gmail.com>
Date: Tue, 14 Jan 2025 00:14:00 +0800
From: Guan-Yu Lin <guanyulin@...gle.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: gregkh@...uxfoundation.org, Thinh.Nguyen@...opsys.com, 
	mathias.nyman@...el.com, perex@...ex.cz, tiwai@...e.com, 
	sumit.garg@...aro.org, kekrby@...il.com, oneukum@...e.com, 
	ricardo@...liere.net, lijiayi@...inos.cn, quic_jjohnson@...cinc.com, 
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-sound@...r.kernel.org
Subject: Re: [PATCH v7 5/5] usb: host: enable USB offload during system sleep

On Thu, Jan 9, 2025 at 11:08 PM Alan Stern <stern@...land.harvard.edu> wrote:
>
> On Thu, Jan 09, 2025 at 03:55:09AM +0000, Guan-Yu Lin wrote:
> > Sharing a USB controller with another entity via xhci-sideband driver
> > creates power management complexities. To prevent the USB controller
> > from being inadvertently deactivated while in use by the other entity, a
> > usage-count based mechanism is implemented. This allows the system to
> > manage power effectively, ensuring the controller remains available
> > whenever needed.
> > In order to maintain full functionality of an offloaded USB devices,
> > several changes are made within the suspend flow of such devices:
> > - skip usb_suspend_device() so that the port/hub are still active for
> >   USB transfers via offloaded path.
> > - not flushing the endpoints which are used by USB interfaces marked
> >   with needs_remote_wakeup. Namely, skip usb_suspend_interface() and
> >   usb_hcd_flush_endpoint() on associated USB interfaces. This reserves a
> >   pending interrupt urb during system suspend for handling the interrupt
> >   transfer, which is necessary since remote wakeup doesn't apply in the
> >   offloaded USB devices when controller is still active.
>
> Does this reasoning apply to interrupt-OUT as well as interrupt-IN?
>

Interrupt-OUT endpoints seem unnecessary in our current use cases. Our
primary concern lies with interrupt-IN endpoints, specifically those
associated with the remote wakeup feature.
Remote wakeup presents a unique challenge within our audio offloading
model during system suspend. Functions typically reliant on remote
wakeup, such as key-events, bypass remote wakeup because the
controller remains active during system suspend. Consequently, these
functions are handled as if the system were active, with events
received by a pending URB. Flushing the endpoint would remove this
pending URB, leaving no mechanism to handle these interrupt events.
Therefore, we should avoid flushing endpoints associated with remote
wakeup to ensure continued functionality for audio offloading during
system suspend.

>
> Or looking at it another way: Since the device's endpoints are being
> used by the coprocessor, should the system flush any of them at all?
>
Our local experiments reveal issues when we flush interrupt endpoints.
For other endpoints, we didn't see any problem. However, since
usb_hcd_flush_endpoint() still modifies the endpoints, it'll be better
to avoid flushing the endpoints associated with the offloaded USB
devices. This could mitigate potential conflicts in the future.

Regards,
Guan-Yu