On Thu, Feb 24, 2005 at 01:50:59PM -0800, David Brownell wrote:
> 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.
Well, I finally got rid of using lsusb entirely--it's nice to not have
to fork a process, and it's very nice to not have to parse output, so
I'll probably opt to not have that information over bringing that
stuff back in. (I think this particular case is actually academic--the
only way for users to send diagnostic data to us from the system is
via the USB pen drives themselves, so if those aren't working ...)
Besides, if there are known-problematic drives out there, I should
probably just buy one for testing ...
The code now is pretty nice: scan /sys/block, weed out non-removable
devices, follow the device symlink, do some trivial parsing of the
path to see if it's a USB device and to pull out the last-hop port
number, and then read a few one-line files to get the serial, etc.
No forked processes, minimal parsing, querying another attribute is
as simple as reading eg. 'd.sSysPath + "device/../manufacturer"'.
I've been pretty impressed by sysfs.
(We used to have to use serial numbers to match up lsusb output with
/proc/scsi/usb-storage/ files, and then use the usb-storage filename
to connect that to a /dev/sd? device--things are a lot nicer in 2.6. :)
> The "001" is available from the sysfs path, and I thought the "002" was
> a sysfs attribute ("address" or something).
"002" is in devnum, but putting all this together to a working usbfs
path means some parsing, assuming that the paths are three digits, etc.
It's much nicer to have the kernel just tell me where to look. Sysfs
does just that via symlinks, which is one of the things I found very
useful--I no longer have to pick a common attribute between different
sets of data, since the link is just provided.
> 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.
Okay. What I wasn't sure about was whether there was a separate upper
limit on a bus-powered hub as a whole--whether you could draw 100mA from
all four ports, since the hub had a sysfs "maxpower" attribute that
said "100mA". I guess that's the max power usage of the hub itself, not
including potentially attached devices.
> (*) 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.
> 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...)
Ick. That would mean that attaching a bus-powered hub, which uses 100mA
itself, would only have 100-150mA available for the total of all devices,
right?
Is this information correctly reported by the USB host? We use off-the-
shelf motherboards, which have a habit of being discontinued periodically,
which means we have to change production motherboards from time to time.
If some boards can't supply enough power to get at least 100mA per port
(to two ports, not four) on our bus-powered hub, that's an important point
for us when evaluating replacement boards.
--
Glenn Maynard
-------------------------------------------------------
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
