On Tue, Apr 10, 2012 at 5:33 PM, James Haigh <james.r.haigh@xxxxxxxxx> wrote: > But can a powered hub be told to restrict a specific port to 1 unit load? No, a powered hub cannot be told such a thing. The hub offers up +5V; it is up to the device to determine how much it will draw. > I know that when a USB port gets overloaded or shorted, it cuts the > power. So there /is/ built-in possibility for this. Is there really no > way of accessing this functionality? It's such a shame and a massive > oversight in the hardware if there isn't. Generally, that functionality is implemented with a self-healing fuse. Go over the limit (whatever it is set to), and the fuse opens momentarily, and then closes a short time later. There is no software or gate-based logic involved at all. The chipsets often have an OC# input to let them know when an over-current event has occured, so the proper reset sequence can be followed. > 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. > I think each port should have 3 additional power options: Off, 100mA, > 500mA. If the spec allows powered devices to run without VBUS (which I > very much doubt), I would hope for a 4th option, 0mA, which cuts VBUS > but still allows data transfer. If VBUS is down, device detection doesn't work. You can't tell if a device is plugged-in or not. > It seems a huge oversight in general in the USB spec that USB devices > cannot be programmatically disconnected and reconnected. Surely it > should have been a requirement of the standard. :-( It was a use case that just wasn't considered. After all, you can issue a reset to the device programmatically. This was also designed as a "consumer" technology; these sorts of unattended use cases just didn't factor in. > On 09/04/2012, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > ... >> I'm sorry; what you're asking for is not possible. The USB controller >> hardware most commonly used in desktop and laptop systems does not >> offer any way for software to restrict the amount of current. In USB, >> the amount of current used is determined by the device, not by the >> host. If you want to reduce a phone's usage to 100 mA, you have to do >> it by telling the phone -- telling the host won't accomplish anything. > > Yes, although isn't this done in a standard way? The host should tell > the device to keep below 100mA, and the host should cut the power if > the device overloads. The device can, optionally, advertise multiple configurations which use differing amounts of power. However, very very very few devices actually do this. I do recall hearing about a Blackberry which did this 3-4 years ago... but I think that was the only one. Most devices advertise only one configuration which draws the maximum power the device will ever draw. >>> Apparently USB ports can be disabled, and when this occurs no power is >>> supplied. >> >> No, power is still supplied when the port is disabled. > > Oh. :-( > > What about overload protection? Overload protection always applies. > 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. >> Disconnecting and reconnecting are physical acts -- they require >> somebody to unplug and replug a cable. There is no way to do these >> things in software. (Not unless your computer has a robot hand that >> can unplug and replug USB cables :-) > > They can quite happily be approximated by transistors. Only if that was in the spec, which it wasn't. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux -- 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
