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

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 9.6.2022 16.48, Alan Stern wrote:
> On Thu, Jun 09, 2022 at 10:59:37AM +0300, Mathias Nyman 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.

Correction,  we can get USB 3 links to ss.Disabled and port to Disabled state
by setting the PORTSC PED bit.
USB 2 link goes to Polling, port Disabled.

Port power is left untouched.
This could work.

> 
> What would happen if you clear the PP bit, wait for the link state to
> become ss.Disabled, and then turn PP back on?

For USB 3 devices host will detect the device, and do all steps until device is
in an enabled U0 state. All without driver interaction, and even if host is not running.

USB 2 devices probably stop in Disabled/link:Polling waiting for driver port reset

> 
>> 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.
> 
> In theory the problem could affect systems having any kind of xHCI
> hardware, since it's really a defect in the system firmware.
> 
> Doesn't Windows have a hibernation mode?  Do you know what state it
> leaves the xHCI ports in during hibernation?

Good question, haven't looked into what windows does here.
I think this problematic boot firmware is specific for non-windows systems.
but again, not sure.
Worth looking into

Thanks

-Mathias