On Thursday 24 February 2005 11:45 am, Glenn Maynard wrote:
>
> Also, reading /proc/bus/usb/devices or lsusb -v will (currently) query
> string descriptors, even if I don't want them at all (and usb/devices
> will do so for all devices, not just the ones I'm interested in).
Feel free to submit a patch against lsusb (CVS), maybe adding/documenting
a new flag that says not to do no more than read /proc/bus/usb/BBB/DDD
files. There's already a way to say "just look at device BBB/DDD",
you may have missed that.
> I suppose that the cross-referencing problems could be fixed, at least,
> by having a file with the relative usbfs path of the device: "usbfs" =
> "001/002". (The information still wouldn't be as easily available,
> though.)
The "001" is available from the sysfs path, and I thought the "002" was
a sysfs attribute ("address" or something).
> > It's probably not a good idea to prefer the lower-power configuration by
> > default. A better heuristic might be to prefer the highest-power
> > configuration that fits within the parent hub's power budget.
>
> A quick look suggests that doing this against the 100mA per-port cap
> should be fairly easy, but I don't know how to do this for the power
> limit of the whole hub:
For bus-powered hubs, there's a ceiling of 100mA per port in all cases.
For self-powered hubs there's _usually_ a ceiling of 500mA per port.
The exception is that some (self-powered) root hubs have limits on the
amount of power they put out. For example, they might not be able to
put more than 250 mA out on their single port, or they might have two
ports each limited to 200mA. (I picked those examples because I happen
to have boards with those specific limitations...)
Somewhere I've got patch to handle a bug I found in that area too.
Basically, when you plug a bus-powered hub into one of those ports,
the power budgeting currently goofs because it assumes there'd be
enough power for all ports. E.g. 100 for the bus powered hub, 80
for a USB keyboard it's built in to, leaving 70 mA available ... but
that's not what the math currently concludes!
> when the first device is inserted, it needs to
> choose a low-enough power config that we have enough for the second card
> that's not inserted yet (and, presumably, without having to second-guess
> and change the configuration later).
Keep it simple ... if the hub is bus powered, select a config that's
at most 100mA, or fail. Don't second-guess, since any additional
devices you plug in may very reasonably fail to enumerate. (But one
hopes they won't glitch the power on the already-connected devices!)
> Since the power limit of the whole
> hub appears to also be 100mA, that seems to be--for this particular
> case--"prefer the highest-power configuration <= 50mA" (100mA over 2
> devices). Is there a better approach?
Given that the power budget for a bus-powered hub is 100mA per port,
as adjusted by (a) the hub's own internal usage, at most 100mA(*), and
(b) the parent hub maybe giving less than 500mA, I'm not sure how
that changes your question.
- Dave
(*) Notice how 500mA from powered hubs, less 100mA bus power for
the hub, leaves 400mA at 100mA/port == 4 ports max. That's
exactly why bus powered hubs aren't very big.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
