Linux USB內核驅動程序如何與USB Wi-Fi卡內的EEPROM交互？

Question

我想了解使用RTL8187 Wi-Fi芯片與Wi-Fi卡相關的Linux驅動程序源代碼。具體來說，我試圖在USB協議層跟蹤Linux與ALFA AWUS036H USB Wi-Fi卡的交互。我一直在使用兩種方法來做到這一點的源代碼和2)迄今1)把printk()陳述觀看的usbmon的十六進制輸出。使用這兩種方法我可以追蹤什麼正在發生低的水平，但沒有爲什麼任何理解它是在一個較高水平發生。

在這一點上我特別注意的是，它看起來好像rtl8187驅動程序所做的第一件事情是USB設備中的EEPROM上的一整個讀/寫操作，而我沒有很好的理解EEPROM如何在USB設備內部（或者外部）工作。作爲一個例子，我已經把打印語句周圍的代碼行中/usr/src/linux/drivers/net/wireless/rtl818x/rtl8187/dev.c，我相信從USB Wi-Fi卡的MAC地址是閱讀：

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的高脈衝和低脈衝，以及操作之間的特定（雖然非描述性）時間延遲，這似乎意味着不存在這樣的抽象。我真的不知道該從哪裏開始瞭解所有元素如何一起工作。

Answer 1

這真的取決於芯片上。

有時（不在這種情況下，雖然）司機只會詢問芯片「給我EEPROM中的N個字節開始偏移O」的，然後它是由芯片實際上與EEPROM通信，獲取數據並將其提供給驅動程序。在這種情況下，驅動程序不需要知道它是什麼樣的eeprom或如何與它交談。

在其他情況下，像這樣，芯片只是通過USB接口暴露所有（或大部分）存儲器映射，而驅動器則通過從必要存儲器位置讀取/寫入來完成所有工作。連接到eeprom的芯片上的引腳可通過該存儲器映射進行訪問，並且在這種情況下對eeprom的訪問是通過對串行協議進行位反轉來實現的。

所以，爲了使驅動讀取MAC的值解決由讀/在存儲器映射中寫入適當的寄存器，將讀/寫這些引腳一次一個。每當一個引腳切換或讀取多個控制消息時都會進行交換，這就是爲什麼你會看到如此多的控制消息。

這樣做的一個原因是爲了降低成本，儘可能多地在驅動程序中完成邏輯，而不是芯片本身。現在，這樣做，特別是通過USB，這是非常低效的（與其他方法相比），但是對於這種情況下的EEPROM訪問，這並不重要，因爲它很少進行。