On Mon, 31 May 2004, Sebastian Henschel wrote: > > > topology: portNumber, count > > > > The port # is available as the last part of the directory name, the part > > following the final '-' or '.'. > > really? > > a directory named "1-1" in sysfs should mean bus# 1 and port# 1?
That's right. > but this devices shows port# 0 in proc. I'm not sure if that's deliberate or a bug in the procfs interface. The port numbers in /proc/bus/usb/devices use origin 0; the port numbers in sysfs use origin 1. > i have a directory here in sysfs named > 1-1:1.0 > . comparing that with other items in sysfs and the info given in proc, it > more looks like > bus# 1, count, config#, iface# No, it's bus #1, port 1, config 1, interface 0. The corresponding proc entry would say port 0. The count value is subject to change (if a device is plugged into port 3 and the other ports are vacant then its count would be 1; when a device gets plugged into port 2 the port-3 device's count would change to 2) but the port value is stable until you physically move the cable. > is there any documentation about this in <kernelsrc>/Documentation/usb/? > or on linux-usb.sf.net? There's some documentation about /proc/bus/usb/devices in Documentation/usb/proc_usb_info.txt. I don't think there's any documentation of the sysfs interface, just comments in the source code. > > > is it somewhat planned to include these? > > > > I don't know what anybody else is planning, but I don't have any plans to > > change the way this works. > > so the current "way this works" is, that this info is unavailable in > sysfs? That's right. Part of it is understandable, since sysfs only reports information about devices that exist. Interfaces for non-active configurations and non-active altsettings don't exist as devices, so they shouldn't have entries in sysfs. > sorry, i did not express myself cleanly. what i wanted to write was: > in order to make that info available under sysfs, must every driver be > programmed to do so (which would be more error-prone but might have > other advantages) or is there a generic way for the usb-sysfs base code > to retrieve that info? with base code, i mean the code used by all > drivers or base classes or stuff included by usb.h or whatever the right > nomenclature is. There's a generic piece of code in drivers/usb/core/driverfs.c that implements all these sysfs attributes. > but some day, /proc/bus/usb/devices will go away and be replaced by > /sys/bus/usb/devices/, when sysfs has matured enough... or not? if not, > it seems i did not get the right idea of sysfs yet. why duplicating all that > info from proc, then? I don't know about that. As you've noticed, a lot of the information in /proc/bus/usb/devices isn't available in sysfs. For that reason alone, the procfs interface probably won't go away -- or if it does, the information will be presented in some other form. The information in sysfs shows the device's _current_ settings. The information in procfs shows _all the available_ settings. So naturally there's an unavoidable overlap. Some of the things you mentioned, such as bandwidth allocation information, could easily be added to sysfs (and maybe it should be). It would be available only in the directory for the root hub, though -- the kernel doesn't keep track of bandwidth allocation by individual device but only per bus. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
