CODEWITHSUNDEEP
linux-kerneldriverwifi
charlesw
charlesw

Reputation: 612

How does the Linux kernel know which driver functions to call?

I am looking at the 802.11 Realtek driver code from https://github.com/o11s/open80211s/tree/master/drivers/net/wireless/rtl818x/rtl8180 and can’t figure out how either the kernel knows which driver functions to call.

For example, how does it know if it needs to call write_grf5101 or rtl8225_write in order to transmit a datagram?

From rtl8225.c:

static void rtl8225_write(struct ieee80211_hw *dev, u8 addr, u16 data)
{
...
}

From grf5101.c:

static void write_grf5101(struct ieee80211_hw *dev, u8 addr, u32 data)
{
...
}

Upvotes: 0

Views: 1487

Answers (1)

user8549610
user8549610

Reputation:

These two functions are not called by the kernel itself. They are static and reside in corresponding files (probably, chip-specific files). Also, it seems like they are not used as callbacks in either place.

Instead, you may see that, for example, write_grf5101() is used by grf5101_rf_init() function in ./drivers/net/wireless/realtek/rtl818x/rtl8180/grf5101.c file, and that function is set as a callback in rtl818x_rf_ops structure which in turn, as you might understand, is some sort of like more generic entity within the driver. For instance, that grf5101_rf_ops variable (which is of type struct rtl818x_rf_ops) is set as a callback table by rtl8180_probe() function in ./drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c. And, finally, the latter rtl8180_probe() is set as a callback in rtl8180_driver variable of type struct pci_driver which, as you might see, is some sort of like an interface maintained by the kernel itself (all PCI devices register themselves with struct pci_driver). The line module_pci_driver(rtl8180_driver); below performs such registration in this particular case.

So, the point is that "the kernel" doesn't know (and probably shouldn't) about such tiny static helper routines. Instead, the kernel needs a PCI device description structure which in turn will be used all way round to interface a particular device. A typical driver, however, may have (and often has) its internal callback structures - often chip-specific (in the case when the driver is designed to serve multiple chips in some sort of like device family) - which in turn will point to chip-specific functions located in the corresponded .c files. That internal functions may use such helpers (like rtl8225_write() or write_grf5101()), and there is nothing to do with kernel in that case. They are just some tiny chip-specific helpers.

Upvotes: 2

Related Questions