From: Pete B. <pb...@gm...> - 2011-07-02 23:32:49
|
On 2011.07.02 02:44, Xiaofan Chen wrote: > BTW, I wonder if you could help me by explaining why this leads to the failure > of listing the NEC/Renesas root hub from lsusb. Sorry I am a bit slow > in reading the > complicated codes. No problem. While I still don't understand why the Renesas root hubs are listed under the "NUSB3" symbolic bus name rather than "USB", when all of the other USB 3.0 seem to be, I will try to clarify what I can. > http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=libusb/os/windows_usb.c;hb=HEAD;js=1 > 1214 #define HCD_PASS 0 > 1215 #define HUB_PASS 1 > 1216 #define GEN_PASS 2 > 1217 #define DEV_PASS 3 > > I think that the HCD pass will find the Renesas USB 3.0 host controller, > the HUB pass will find the Renesas USB 3.0 root hub. The GEN pass should > not matter since it is meant to find driverless device, right? Wrong? Well, you're pretty much spot on with regards to the HCD and HUB passes picking up all the host controllers and hubs, as well as some of the intent of the GEN pass, but I guess I've got to provide some insight as to why the order of the passes is actually not what decides instantiation, and why the GEN pass has actually more weight than all the others Basically, up until Renesas decided that using the "USB" symbolic bus name was not something they wanted for their root hubs, getting a list of everything under "USB" with SetupDiGetClassDevs() was the most efficient way to get a list of _ALL_ the USB devices currently connected (including driverless), which is pretty much what we want to retrieve in libusb. So the GEN pass is really our base. And if we could retrieve all the properties we need for libusb enumeration through the GEN pass alone, it would be our only pass, because it really lists (or used to list) all the devices we want. Again, I think new enum becomes easier to understand once you realize that GEN is the one pass around which everything else revolves. Unfortunately, while the GEN pass is incredibly efficient for enumerating all currently connected USB devices, because it is not GUID based it doesn't help retrieving some of the other properties we need to provide as part of libusb. Therefore, we need to add extra passes, some of which intervene before (HUB, HCD, as having those allows us to create a parent-child relationship, and query the parent hub to retrieve and cache the device descriptor for instance) and some after (DEV as well as any extra class GUID we need to list, extra GUIDs which, and this also has some importance, we also retrieve from the GEN pass). But the GEN pass is actually the only pass where we invoke discovered_devs_append(), which effectively places the device on the libusb list,. Thus, if a device isn't listed during GEN, we may process it internally during the other passes, as is the case for HCDs, but it will not be made available to libusb. > Then the > DEV pass will find the USB device attaches to the USB 3.0 root hub. Not exactly. USB device attached to the USB 3.0 root hub will already have been found during the GEN pass. Maybe one thing I wasn't clear enough about is that non root USB 3.0 devices are listed under the "USB" PnP symbolic bus name. It's only the root hubs that appear to be listed only under "NUSB3". So again, what happens really is that, the GEN pass adds all devices to the list, including 3.0 ones, except root hubs because these are now listed under a different bus designation than "USB". Regards, /Pete |