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. What would happen if you clear the PP bit, wait for the link state to become ss.Disabled, and then turn PP back on? > 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? Alan Stern
