Идентификатор поставщика и идентификатор продукта определяют драйвер, используемый для устройства USB?

Скажем, у меня есть USB-устройство с идентификатором поставщика (VID) 0123 и идентификатор продукта (PID) abcd .

 0123:abcd 

Согласно USB.org , присвоение идентификатора продукта полностью зависит от производителя.

Идентификаторы продуктов (PID) присваиваются каждым поставщиком по своему усмотрению

Таким образом, нет ничего, что помешало бы ошибочному поставщику продавать широкий спектр USB-устройств, все они нуждались бы в разных драйверах, и все они использовали бы те же идентификаторы поставщиков и продуктов.

 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 признает, что это потенциальное поведение поставщика может быть проблематичным.

Повторяющиеся номера могут вызвать ошибку драйвера

В случае, когда идентификаторы повторно используются для карточек, требующих разных драйверов, есть ли что-то, что может сделать ОС для определения соответствующего драйвера?

Есть ли другие поля, представленные USB-устройством, которые могут использоваться (или обычно используются) для вывода соответствующего драйвера? Я предполагаю, что для определения этого параметра используются только идентификатор поставщика и идентификатор продукта.

Или будет типичная система * nix предположить, что существует одна <-> одна связь между 0123:abcd и драйвером, который должен использоваться, и поэтому все, что он может сделать, это выбрать один драйвер, который, по его мнению, подходит?

Я предполагаю, что, как правило, используются только идентификатор продавца и идентификатор продукта, что только ручное вмешательство пользователя при загрузке надлежащего драйвера будет работать, и что нечего делать, кроме того, что он расстраивается у продавца, чтобы сделать вещи запутанными.

Существуют некоторые другие сведения, которые можно использовать для выбора драйвера устройства: номер версии, класс устройства, подкласс и протокол, а также класс интерфейса, подкласс и протокол. (Что касается драйверов на Linux, посмотрите на макросы USB_DEVICE . Вы можете получить представление об информации, доступной путем looling на выходе lsusb -v .)

Как и следовало ожидать, этого все еще недостаточно, поэтому, прежде чем драйвер фактически зарегистрирован для устройства, ядро ​​вызывает функцию пробника в драйвере. Эта функция позволяет решить, действительно ли устройство поддерживается драйвером. В общем говоря, в Linux устройства с одним и тем же идентификатором, но с разными реализациями обрабатываются одним и тем же драйвером, что позволяет избежать сопоставления нескольких драйверов с одним устройством. Чтобы увидеть исключения из этого правила, вы можете запустить

 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 

в котором перечислены несколько драйверов, которые соответствуют конфликтующим идентификаторам (ни один из которых не является драйверами устройств USB).

(Позже я расскажу о двух типах поведения.)