2

我正在尝试了解与使用 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，以及操作之间的特定（尽管非描述性）时序延迟，这似乎意味着不存在这样的抽象。我真的不知道从哪里开始了解所有元素如何协同工作。

4

1 回答 1

4

这真的取决于芯片。

有时（虽然不是这种情况）驱动程序会简单地询问芯片“给我从偏移量 O 开始的 eeprom 的 N 个字节”，然后由芯片实际与 eeprom 通信，获取数据并提供它给司机。在这种情况下，驱动程序不需要知道它是什么类型的 eeprom 或如何与之交谈。

但在其他情况下，就像这个一样，芯片只是通过 USB 接口公开其所有（或大部分）内存映射，驱动程序通过读取/写入必要的内存位置来完成所有其余的工作。芯片上连接到 eeprom 的引脚可通过该内存映射访问，在这种情况下，对 eeprom 的访问是通过对串行协议进行 bit-banging 来实现的。

因此，为了让驱动程序读取 MAC 地址的值，它将通过读取/写入内存映射中的适当寄存器一次读取/写入这些引脚。每次切换或读取引脚时，都会交换几条控制消息，这就是为什么您会看到如此多的消息。

这样做的一个原因是尽可能多地在驱动程序中完成逻辑，而不是由芯片本身完成，以降低成本。现在，这样做，尤其是通过 USB，效率非常低（与其他方法相比），但是在这种情况下，对于 EEPROM 访问来说，这并不重要，因为它很少进行。

于 2012-08-09T10:31:21.857 回答