Как драйверы ядра Linux USB взаимодействуют с EEPROM на картах USB Wi-Fi?
Я пытаюсь понять исходный код драйвера Linux, связанный с картами Wi-Fi, используя чип Wi-Fi RTL8187. В частности, я пытаюсь отследить взаимодействие Linux с USB-картой ALFA AWUS036H USB на уровне протокола USB. Я использовал два метода, чтобы сделать это до сих пор 1)
сдачи printk()
заявления в исходном коде и 2)
просмотр шестнадцатеричного вывода usbmon
, Используя эти два метода, я могу проследить, что происходит на низком уровне, но не понимая, почему это происходит на высоком уровне.
Что меня особенно привлекло в этот момент, так это то, что драйвер rtl8187 в первую очередь выполняет целую загрузку операций чтения / записи на EEPROM внутри устройства USB, и у меня нет хорошего понимания как EEPROM работают внутри USB-устройств (или вне этого). В качестве одного примера, я поместил операторы печати вокруг строки кода в /usr/src/linux/drivers/net/wireless/rtl818x/rtl8187/dev.c
Я считаю, что читает в MAC-адрес с карты Wi-Fi USB:
printk(KERN_INFO "COMMENCING reading MAC address, I think...");
eeprom_93cx6_multiread(&eeprom, RTL8187_EEPROM_MAC_ADDR,
(__le16 __force *)mac_addr, 3);
printk(KERN_INFO "DONE reading MAC address, I think...");
Теперь я ожидал, что что-то вроде этого может генерировать всего несколько управляющих сообщений USB, но другие printk()
заявления, которые я имею в подпрограммах eeprom_83cx6_multiread()
Предположим, что эта простая операция генерирует порядка 60 или более операций чтения управляющего сообщения USB и, вероятно, столько же операций записи управляющего USB.
Есть ли какое-нибудь высокоуровневое руководство, где объясняется, как взаимодействуют USB и EEPROM внутри USB-устройств? Я как бы в растерянности относительно того, где начать искать больше информации. Я всегда предполагал, что что-то вроде EEPROM будет абстрагировано от USB-программатора с простыми USB-сообщениями, которые устройство затем преобразует во все, что должно происходить в EEPROM. Подробнее о коде драйвера USB, хотя похоже, что в EEPROM отправляются импульсы высокого и низкого импульсов, а также конкретные (хотя и не описательные) временные задержки между операциями, что, по-видимому, не означает, что такой абстракции не существует. Я действительно не знаю, куда пойти, чтобы понять, как все элементы работают вместе.
1 ответ
Это действительно зависит от чипа.
Иногда (ноне в этом случае) драйвер просто спрашивает микросхему: "дайте мне N байтов из EEPROM, начиная со смещения O", а затем микросхема должна фактически связаться с EEPROM, получить данные и дать их водителю. В этом случае водителю не нужно знать, что это за EEPROM или как с ним разговаривать.
Однако в других случаях, как этот, чип просто открывает всю (или большую часть) своей карты памяти через интерфейс USB, а драйвер делает все остальное, считывая / записывая данные из / в нужные места памяти. Контакты на микросхеме, подключенные к EEPROM, доступны через эту карту памяти, и доступ к EEPROM в этом случае осуществляется путем последовательного побитового последовательного соединения.
Таким образом, для того, чтобы драйвер считал значение MAC-адреса, он будет считывать / записывать в эти контакты по одному, читая / записывая соответствующие регистры в карте памяти. И каждый раз, когда пин-код переключается или читается, несколько обменных сообщений будут обмениваться, поэтому вы видите их так много.
Одна из причин для этого заключается в том, чтобы как можно больше логики выполнялось в драйвере, а не самим чипом, чтобы снизить затраты. Теперь делать это, особенно через USB, довольно неэффективно (по сравнению с другим подходом), однако для доступа к EEPROM в этом случае это не имеет большого значения, потому что это делается довольно редко.