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
