How and from where is the ENC28J60 driver loaded?

Question

I have a raspberry CM3 setup where I added an external eNet port so that I have internet connectivity. It is very similar to the break-out board setup such as this one which is also based on the ENC28J60 ethernet microcrontroller.

I have managed to get it working by adding a device tree overlay. The pi loads the driver and everything functions properly. However I want to change some setting in the driver (the behaviour of the LEDs). This means I have to change some values in the register of the microchip. Now I am a bit puzzled how to do this.

What I found:

1. The source code of the driver: link
2. The source code of a device tree overlay: link

So my best guess is to download the source code of the driver, change the values of the registers I want to change and then recompile the driver. My question with this is:

1. How does the raspberry know what driver to load? I would expect this information to be listed in the device tree overlay?
2. Where is the driver located? (and thus, where do I put my newly compiled driver?)

Answer 1

That's not the source code for the linux driver. This is.

How does the raspberry know what driver to load?

I'll make an educated guess.

Many or most device drivers are auto-loaded. If you look at the bottom of that module source file, you'll find a MODULE_DEVICE_TABLE() invocation. Presumably that's a macro evaluated at compile time; for more about how it works, see here. Point being, the driver is registered in a look-up table keyed on information the device provides when it announces itself.

However, in this case I think the DTO pre-arranges this, which may be prerequisite of SPI devices (i.e., their drivers cannot be auto-loaded). Notice that the DTO source you linked includes compatible = "microchip,enc28j60", also used in the struct registered with MODULE_DEVICE_TABLE in the driver source (line 1650).

Where is the driver located?

Kernel modules for the loaded kernel are in /lib/modules/$(uname -r); $(uname -r) gives you the current kernel version. Drivers must be compiled specifically for it using the same source and configuration.

Unfortunately, judging by some of the experiences here, this still may not work, perhaps because the pre-built Pi kernel stupidly does not expose its configuration, contra standard practice. Worst comes to worst, you have to build your own kernel too.

For more about how linux drivers work, start here.