Home/ Questions/Q 8362105
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T11:51:54+00:00

I am trying to understand the Linux driver source code associated with Wi-Fi cards

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It really depends on the chip.

    Sometimes (not in this case though) the driver would simply ask the chip “give me the N bytes from the eeprom starting at offset O” and then it is up to the chip to actually communicate with the eeprom, get the data and give it to the driver. In this case the driver doesn’t need to know what kind of eeprom it is or how to talk to it.

    In other cases though, like this one, the chip simply exposes all (or most) of its memory map over the USB interface and the driver does all the rest by reading/writing from/to the necessary memory locations. The pins on the chip that are connected to the eeprom are accessible through that memory map and the access to the eeprom in this case happens by bit-banging the serial protocol.

    So, in order for the driver to read the value of the MAC address it will read/write to these pins one at a time by reading/writing the appropriate registers in the memory map. And each time a pin is toggled or read several control messages will be exchanged, which is why you are seeing so many of them.

    One reason for doing that way is to have as much as possible of the logic being done in the driver instead of by the chip itself in order to lower costs. Now, doing this, especially over USB, is quite inefficient (compared to the other approach), however for EEPROM access in this case it doesn’t really matter because it is done fairly infrequently.

    • 0