On Tue, 20 May 2014, Dan Williams wrote: > From: Lan Tianyu <tianyu.lan@xxxxxxxxx> > > describe the mechanisms for controlling port power policy and > discovering the port power state. > +Example of the relevant files for port power control. > + > + child device link + > + port device + | > + parent hub + | | > + v v v > + /sys/bus/devices/usb2/2-0:1.0/port1/device > + > + /sys/bus/devices/usb2/2-0:1.0/port1/power/pm_qos_no_power_off > + /sys/bus/devices/usb2/2-0:1.0/port1/device/power/control > + /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:<intf0>/driver/unbind > + /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:<intf1>/driver/unbind > + ... > + /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:<intfN>/driver/unbind These port names are out of date. Likewise the names below. +While a superspeed port is powered off a device may downgrade its +connection and attempt to connect to the hi-speed pins. The +implementation takes steps to prevent this: + +1/ Port suspend is sequenced to guarantee that hi-speed ports are powered-off + before their superspeed peer is permitted to power-off. The implication is + that the setting pm_qos_no_power_off to zero on a superspeed port may not cause + the port to power-off until its highspeed peer to go to its runtime suspend s/to go/has gone/ + state. Userspace must take care to order the suspensions if it wants to + guarantee that a superspeed port will power-off. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
