5

Say I have a USB device with a vendor id (VID) of 0123 and a product id (PID) of abcd.

0123:abcd

According to USB.org, product id assignment is entirely up to a manufacturer.

Product IDs (PIDs) are assigned by each vendor as they see fit

So there's nothing stopping a misguided vendor from selling a wide range of USB devices, all needing different drivers, and all using the same vendor and products ids.

USB Device A (needs driver X) -> 0123:abcd
USB Device B (needs driver Y) -> 0123:abcd
USB Device C (needs driver Z) -> 0123:abcd

USB.org acknowledges that this potential vendor behavior can be problematic.

Duplicate numbers may cause driver error

In a case where the ids are reused for cards needing different drivers, is there anything the OS can do to determine the appropriate driver?

Are there any other fields presented by the USB device that can be used (or are typically used) to infer the appropriate driver? I'm assuming only vendor id and product id are used to make that determination.

Or will a typical *nix system assume that there's a one <-> one relationship between 0123:abcd and the driver that should be used, and so all it can do is choose the 1 driver it thinks is appropriate?

I'm guessing, if only vendor id and product id are typically used, that only manual user intervention in loading the proper driver will work, and that there's not much else to do aside from being upset at the vendor for making things confusing.

2

There are some other pieces of information which can be used to select a device driver: a version number, the device class, subclass and protocol, and the interface class, subclass and protocol. (For the driver side of things on Linux, look at the USB_DEVICE macros. You can get an idea of the information available by looling at the output of lsusb -v.)

As you’d expect that’s still not enough, so before a driver is actually registered for a device, the kernel calls a probe function in the driver. That function gets to decide whether the device is actually supported by the driver. Generally speaking though, on Linux, devices with the same id but different implementations are handled by the same driver, which avoids having to map multiple drivers to one device. To see the exceptions to this rule, you can run

find /lib/modules/$(uname -r) -name \*.ko | xargs /sbin/modinfo | awk '/^filename:/ { filename = $2 } /^alias:/ { printf "%s %s\n", filename,$2 }' | sort | uniq -D -f 1 | uniq -u | less

which will list the few drivers which match conflicting ids (none of which are USB device drivers).

(I'll expand on both types of behaviour later.)

  • Thank you Stephen. That's very helpful. I did not realize so many fields could come into play when selecting a device driver, nor did I consider that drivers can support multiple devices. That's also interesting about the probe function. As an aside, this link may be more specific to the USB_DEVICE macros you mentioned kernel.org/doc/html/latest/driver-api/usb/usb.html#c.USB_DEVICE – Will Haley Sep 14 '17 at 0:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.