I am trying to understand the Linux driver source code associated with Wi-Fi cards using the RTL8187 Wi-Fi chip. Specifically, I'm trying to trace the interactions of Linux with an ALFA AWUS036H USB Wi-Fi card at the USB protocol layer. I've been using two methods to do this thus far 1)
putting printk()
statements in the source code and 2)
viewing the hex output of usbmon
. Using these two methods I can trace what is happening low level, but without any understanding of why it is happening at a high level.
What has me caught up specifically at this point is that it looks as though one of the first things the rtl8187 driver does is a whole load of read/writes on an EEPROM inside the USB device, and I don't have a good understanding of how EEPROMs work inside USB devices (or outside for that matter). As one example, I have put print statements around a line of code in /usr/src/linux/drivers/net/wireless/rtl818x/rtl8187/dev.c
that I believe is reading in the MAC address from the USB Wi-Fi card:
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...");
Now I had expected that something like this might generate just a few USB control messages, but other printk()
statements I have within the subroutines of eeprom_83cx6_multiread()
suggest that this simple operation generates on the order of 60 or more USB control message reads and probably just as many USB control writes.
Is there any kind of high-level tutorial somewhere that explains what the interaction is between USB and EEPROMs inside USB devices? I'm kind of at a loss as to where to get started finding more information. I had always assumed something like an EEPROM would be abstracted away from the USB programmer, with simple USB messages that the device would then translate into whatever had to happen at the EEPROM. Digging further into the USB driver code though it looks like there is high and low pulses being sent to the EEPROM, as well as specific (though non-descriptive) timing delays between operations, which seems to imply no such abstraction exists. I really don't know where to go to start understanding how all the elements work together.