On Mon, Oct 14, 2024 at 9:06 PM Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > > On 14.10.2024 11.50, 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. > > I don't think all this is needed to prevent USB controller from being > deactivated while sideband is in use. The modified audio class driver > that uses sideband is still bound to a usb interface device, and all > normal pm reference counting should work. > > To me it looks like this code is tricking pm framework into believing > the usb device and host controller have successfully suspended during > system suspend when they in reality are fully up and running. > > I'm not sure I fully understand the case this series is solving. > > Thanks > Mathias > Your understanding is correct; this series aims to keep necessary devices running while the system is suspended. The goal is to keep USB transfer available via sideband when the main system is asleep. Since we're offloading some USB transfers to another audio DSP, the Linux driver is not involved in queueing transfer TRBs, handling event TRBs, etc., in some specific "offloaded" USB endpoints. The sideband might be bound to a USB interface device to prevent the device from going into runtime suspend, but it seems this doesn't prevent devices from suspending when the system goes into system-wide suspend. So the main purpose of this series is to prevent some related devices being suspended during system suspend. Regards, Guan-Yu
