> > I had assumed that if the "self powered" device status was off, > > Linux could deduce "can't use config #1". Just ruling out the > > option of defaulting to some broken configuration. > > Okay, I get it (I think). You're saying that if the device status > indicates there's no external power source then Linux shouldn't choose a > self-powered config, right?
That was the notion. I think it's what the specs say about how devices advertise their state, but I've not made time to verify. > Right now choose_configuration isn't aware of whether or not the host is > running on batteries. In principle it could be made aware of whether or > not the root hub supplies less than 500 mA per port; would that be > essentially equivalent? The per-port limitation comes from the kind of power switching chip that's in use. Boards may not want the budget 500 mA for USB; even just 100 mA is a lot, except for power-hungry things like laptop PCs. Hosts with, say, 100mA limits might still be receiving AC power. Even if it's just to recharge the battery as quickly as it's getting discharged by USB. :) > > > (Unless I've misunderstood the spec and it wants > > > "local power supply" and "external power supply" to mean different > > > things.) > > > > I'm not sure you should expect such nuances to be treated > > consistently in that spec. Neither case would be "exclusively > > bus powered", devices with either would set the "self powered" > > device status bit. > > Specifications often are nit-picky about such nuances. And sometimes, explicitly NOT picky, and making a point to show examples with different conformant implementations. I think the USB specs do that on the peripheral device side. > They have to be > and they're expected to be. (Consider for instance the care with which > the spec distinguishes among "packet", "transaction", "stage", and > "message".) In this case, though, it looks like the spec messed up and > allowed a potential ambiguity to slip through the cracks. But packets, stages, and so on are visible to both host and peripheral. Details of the power circuitry in the peripheral are clearly visible to the peripheral, which has many options ... and only minimally visible to the host: how much VBUS current does it use? Is that augmented with some other power supply? Not: how many rails, what voltages and currents, what battery type(s), how many cells, etc. > Will it always be true that power-limited root hubs have only one port? That's the only kind I've come across, but it's not a requirement. No rush IMO to handle more than one. > If not, there's a possibility of confusion over whether > hcd->power_budget refers to the total or the per-port value. As I said, the use of power_budget changed over time; it started out as a total, but that's not the algorithm in the spec. It would also be possible to define a high power port as well as a low power one, on the same root hub... e.g. some device with one normal "A" socket plus a Mini-AB OTG port. > There's one aspect that's not clear. 7.2.1 says "Battery-powered hubs > may supply either one or five unit loads per port." How does usbcore know > if a hub can only supply one unit load/port? There's nothing in any > descriptor to indicate such a limitation. That text looks confused. You should see the OTG specs too; they've put more effort into consistent definitions for battery based behavior. For root hubs, that's where the board_specific power budget kicks in. For non-root ones ... you're right. You should get a battery powered hub and see how it behaves. :) - Dave ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
