On Tue, 10 Apr 2012, Matthew Dharm wrote: > > Are there /any/ specific USB hub models at all, that offer to the OS > > specific power control over their ports? > > I believe the hub spec only calls for an "optional" power on/off > control. Certainly nothing of the nature you're talking about. Some hubs (not all!) do offer the ability to turn off power completely to individual ports. None of them, as far as I know, offer the ability to restrict the current to 100 mA. And even if they did, there is no standard way to tell hubs to do such a thing. > > No, it doesn't. I'm talking about battery powered devices. Suspending > > will probably just suspend communication while still drawing 500mA to > > charge it's battery. > > Often, suspending a device actually puts it into a lower-power state. > For example, optical mice, when suspended, generally turn off the LED. > Thus, to execute a "wake up", you need to press one of the mouse > buttons. Indeed, the USB specification says quite clearly that a suspended device is not allowed to draw more then 2.5 mA. Of course, not all devices are careful to obey the spec... And in any case, the spec does not require hubs to limit the current for suspended ports to 2.5 mA. Just the opposite, in fact; Section 7.2.3 of the USB-2.0 spec says: When a hub is in the Suspend state, it must still be able to provide the maximum current per port (one unit load of current per port for bus-powered hubs and five unit loads per port for self-powered hubs). (A unit load is 100 mA.) On the other hand, the spec also says that an unconfigured device must not draw more than 100 mA. So if you want to restrict the current draw of your phone, all you have to do is unconfigure it: echo 0 >/sys/bus/usb/devices/X/bConfigurationValue (where X is replaced with the appropriate path for the device). Of course, when a device is unconfigured, it isn't usable -- you might just as well suspend it and have it use even less power. 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
