On Mon, 16 Jul 2012, Pete Batard wrote: > On 2012.07.16 20:09, Alan Stern wrote: > > The device address is the actual value used on the USB bus to identify > > the device. It is a 7-bit number, and it can take on any value from 0 > > to 127. However 0 is reserved for newly-connected devices; by the time > > a device has been enumerated its address will be > 0. > > > > The device number is the value used by the operating system or other > > software to identify the device. Valid ranges will depend on the > > operating system. Quite often it is the same as the device address, > > but not always. > > Ah OK. Still not clear as to whether having Linux assign 1 to root hubs > means that USB device addresses on the bus, for non newly connected > devices, will start at 2, or at 1...
They start at 2. > From your USB-3 statement below, it > seems that the OS rather than the HCD gets to decide what number goes on > the bus, though Linux might just decrement the number before sending it > on the bus. For non-xHCI controllers (i.e., USB-1 and USB-2), the address appearing on the bus is indeed selected by the OS rather than by the hardware. In Linux it is the same as the device number and nothing gets decremented. This means we lose one possible device address, since 1 will never be used as the address of an external device. In other words, under Linux a single USB bus can support only 126 devices, not 127. In practice, of course, this hardly matters. > On Windows, the value we use to set the libusbx device number, since I > guess what matters to us here is what we should probably call "libusbx > device number", is supposed to be the actual USB device address (for non > root hubs). We basically pick the DeviceAddress field from > USB_NODE_CONNECTION_INFORMATION_EX [1] (which, strangely enough, is set > by Microsoft as an unsigned short...). > > But with Windows not providing an OS device number (that I'm aware of) > and other libusbx platforms using that number instead of the device > address, we may still want to try to harmonize things. As far as I could > see, OS-X and Linux seem to follow the same approach (though the bus > numbering on OS-X is pretty wild). No idea about *BSD. Using the DeviceAddress field as a libusbx device number seems like a perfectly reasonable thing to do. Or DeviceAddress + 1, if you prefer. Does Windows guarantee that the DeviceAddress value is always > 0? > On the other hand, given that we can offer no guarantee that the libusbx > device numbers will always be consistent, maybe providing our users with > an expectation that they can rely on those may not be such a good idea... Well, I suppose root hubs could be considered special cases. Certainly for external devices there should be no expectation that the device number will have any particular meaning. For example, it's likely to change from one session to another if you plug in your devices in a different order. Or if you unplug a device and then plug it in again, it's likely to get a new number. > > (In USB-3, for example, addresses are assigned > > automatically by the host controller hardware and not revealed to the > > operating system. Consequently the OS has to make up a device number, > > which bears no relation to the device address.) > > That's also good to know. I have to check how that translates to > Windows. I guess the USB 3.0 driver makes up a device address for > USB_NODE_CONNECTION_INFORMATION_EX. Probably. > > Getting back to the original question... Root hubs do not have device > > addresses at all, because packets on the USB bus are never addressed to > > the root hub. No packet sent by the host is meant for the root hub, > > whereas every packet sent by an external device is (again, with a few > > special exceptions in USB-3); either way there's no need for a root-hub > > address. > > OK, then that means we probably can't get any descriptors for root hubs > (at least in outside of the potential USB 3 exceptions, should they apply). ? I don't follow. You can get descriptors for root hubs just like descriptors for any other hub. Do you mean that no 'Get-Descriptor' packet gets sent on the bus when you ask for a root hub's descriptor? That's true... but it doesn't prevent you from retrieving root-hub descriptors. The descriptors simply come from the OS's driver rather than from an external device. > > However root hubs do have device numbers. The value depends on the > > operating system. In Linux the root hub's device number is always 1; > > In Windows the value currently used by libusbx is always 255. The > > actual value is rather arbitrary, since it never appears on the USB > > bus. > > OK. Since we have no OS device number to speak of on Windows, and since > we have to choose anyway, we may want to try to bring it closer to what > Linux does by using 1 for root hubs as well, and just increment the > number we pick for configured devices. That would be fine. As long as you're sure it won't end up giving two devices the same number. Alan Stern ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
