我正在尝试使用RTL8187 Wi-Fi芯片了解与Wi-Fi卡相关的Linux驱动程序源代码。具体来说，我试图在USB协议层跟踪Linux与ALFA AWUS036H USB Wi-Fi卡的交互。到目前为止，我一直在使用两种方法1)将printk()语句放在源代码中，2)查看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设备中USB和EEPROM之间的交互？我有点不知道从哪里开始寻找更多信息。我总是假设EEPROM之类的东西会从USB编程器中抽象出来，只需简单的USB消息就可以将设备转换成EEPROM中必须发生的任何事情。进一步深入研究USB驱动程序代码虽然看起来有高低脉冲被发送到EEPROM，以及操作之间的特定（尽管是非描述性的）时序延迟，这似乎意味着不存在这样的抽象。我真的不知道去哪里开始了解所有元素如何协同工作。
答案 0 :(得分：4)
这真的取决于芯片。
有时候（在这种情况下不）驱动程序会简单地要求芯片“从偏移量O开始给出来自eeprom的N个字节”，然后由芯片实际进行通信使用eeprom，获取数据并将其提供给驱动程序。在这种情况下，驾驶员不需要知道它是什么类型的eeprom或如何与它交谈。
在其他情况下，像这样，芯片只是通过USB接口公开其所有（或大部分）存储器映射，驱动程序通过从/向必要的存储器位置读取/写入来完成所有其余的操作。芯片上连接到eeprom的引脚可以通过该存储器映射访问，在这种情况下，通过对串行协议进行位冲击来访问eeprom。
因此，为了让驱动程序读取MAC地址的值，它将通过读/写存储器映射中的相应寄存器一次一个地读/写这些引脚。每次切换或读取一个引脚时，都会交换几条控制信息，这就是为什么你会看到这么多信息。
这样做的一个原因是尽可能多地在驱动程序中完成逻辑而不是芯片本身，以降低成本。现在，这样做，特别是通过USB，效率非常低（与其他方法相比），但是对于这种情况下的EEPROM访问，它并不重要，因为它很少进行。