C代码，为什么将地址0xFF00强制转换为结构？

Question

I am trying to understand some Linux kernel driver code written in C for a USB Wi-Fi adapter. Line 1456 in file /drivers/net/wireless/rtl818x/rtl8187/dev.c (just in case anyone wanted to refer to the kernel code for context) reads:

    priv->map = (struct rtl818x_csr *)0xFF00;

I am curious about what exactly the right operand is doing here - (struct rtl818x_csr *)0xFF00; . I have been interpreting this as saying "cast memory address 0xFF00 to be of type rtl818x_csr and then assign it to priv->map ". If my interpretation is correct, what is so special about memory address 0xFF00 that the driver can reliably tell that what it is after will always be at this address? The other thing I am curious about is that 0xFF00 is only 16-bits. I would be expecting 32/64-bits if it were casting a memory address.

Can anyone clarify exactly what is going on in this line of code? I imagine there's a flaw in my understanding of the C syntax.

Answer 1

Casting an absolute address to a pointer to a structure is a common way in drivers to access the (memory mapped) registers of a device as a normal C structure.

Using 0xff00 works because C doesn't do sign extension of numbers.

Answer 2

0xFF00 is an address in the IO address space of the system. If you look in the code, the address is never directly dereferenced but accessed through IO functions.

For example, in the call

rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD,
                 RTL818X_EEPROM_CMD_CONFIG);

which then calls Linux kernel low level IO functions.

The address is cast to a pointer to a struct to give access to offsets from the adress, example here:

0xFF00 + offsetof(struct rtl818x_csr, EEPROM_CMD)

Note that in the rtl818x_iowrite8 call above, no dereference occurs when passing the &priv->map->EEPROM_CMD argument because of the & operator, only the address + offset is computed. The dereference is further achieved withtin the internal low level functions called inside rtl818x_iowrite8 .

Answer 3

You have to consider this from the device point of view.

Starting at address 0xFF00 inside the address space mapped for the rtl8187 device is a memory range that holds information structured the same way as the rtl818x_csr struct defined here .

So after you logically map that region you can start doing bus reads and writes on it to control the device. Like here (had to cut two more hyperlinks because I don't have the reputation necessary to post more than 3, but you get the point). These are just a couple of examples. If you read the entire file you'll see reads and writes are sprinkled everywhere.

In order to understand why that structure looks that way and why 0xFF00 is used instead of 0xBEEF or 0xDEAD you'll have to consult the datasheet for that device.

So if you want to start looking at kernel code, and specially device drivers, you'll have to have more than just the code. You'll need the datasheet or specifications as well. This can be rather difficult to find (see the gazillions of email threads and articles soliciting open documentation from the vendors).

Anyway, I hope I answered your question. Happy hacking!