Re: [RFC PATCH 0/1] hibernate and roothub port power

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 9, 2022 at 12:58 AM Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> wrote:
>
> On 8.6.2022 16.43, Alan Stern wrote:
> > On Wed, Jun 08, 2022 at 02:47:22PM +0300, Mathias Nyman wrote:
> >> On 8.6.2022 11.19, Oliver Neukum wrote:
> >>>
> >>>
> >>> On 07.06.22 15:58, Mathias Nyman wrote:
> >>>
> >>> Hi,
> >>>
> >>>> In shutdown (S5), with xHCI as host, this can be solved fairly easily
> >>>> by turning off roothub port power in the .shutdown path.
> >>>
> >>> That would suck for the people who charge their phone from their
> >>> computer.
> >>
> >> Good point.
> >> My guess is that xHC port power bits won't actually turn off VBus for those
> >> Sleep-and-charge, or Always-on ports.
> >> VBus is allowed to be on even if port is in power-off state, but usb link state
> >> should be forced to ss.Disabled from other states, like U3.
> >>
> >> Need to try it out, it's possible this turns off VBus for some usb-A ports
> >> on some older systems that earlier (accidentally?) supplied VBus on
> >> "normal" ports after shutdown.
> >
> > How about turning off port power _only_ in the shutdown or unbind path,
> > and setting the port link states to ss.Disabled in the poweroff or
> > poweroff_noirq stage of hibernation (if wakeup is disabled)?  Would that
> > solve the problem of the firmware needing to time out on reboot?
> >
>
> That would be optimal, but unfortunately xHCI doesn't support setting link
> state directly to ss.Disabled. Only way is to clear port power (PP) bit.
>
> To avoid turning off VBus in hibernate we could limit port power bit clearing
> to xHC hosts that don't have the Port Power Control (PPC) capability flag.
>
> We know these xHC hosts don't control power switches, and clearing PP won't turn
> off VBus (xhci 5.4.8, PORTRSC)
>
> This could be a solution for some hosts, but probably not cover all.
> Not sure if the hardware this was reported on has PPC flag set.

It appears it does not, HCCPARAMS1 for both USB controllers seems to
be 0x20007fc1 (missing bit 3). You can check my work in case I made an
error here: https://pastebin.com/9raZc63N
-Evan

>
> Thanks
> Mathias



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux