Device Node Compatible Property in Linux- Explained

Embedded linux






The compatible property of a device node is a property used by the linux kernel to match and load an appropriate driver to handle that device node (driver selection).

The string list provided by the compatible property is matched against the string list supported by the driver. If the kernel finds a match, the driver is loaded, and the probe function is invoked.

The compatible property is a standard property (not a custom property), so it can be found in the Standard Properties section of the Devicetree Specification PDF. The following link is the Devicetree Specification for Release v0.3-40-g7e1cc17- Devicetree Specification Release v0.3-40-g7e1cc17

If you go to the Table of Contents of this PDF, under the Standard Properties section, you will see the compatible property.


Device node compatible property in linux


If you click on this property, it will bring you to its description and example.


Device node compatible property description in linux


So let's go over this text.

So the compatible property value will consist of one or more strings. These strings define devices from most specific to more general from left to right for the appropriate driver selection for the device.

Basically we list either one or several devices in the compatible property. The recommended format is to specify the manufacturer first followed by a comma and then the model of the device. However, the model only can be specified.

In the example above given by the PDF, we see two different devices specified. These are, "fsl,mpc8641" and "ns16550". What this means is that the driver for the mpc8641 by the manufacturer fsl would be the most specific driver for our device. However, the driver for the ns16550 would only work for our device.

As stated in the PDF, "an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general nsl16550 device type."

Also, the PDF states, the strings "allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices".

Let's look at a real example of this in the linux kernel code.

Go to Linux/arch/arm/boot/dts/am335x-boneblack.dts

Right at the first node, the root node, marked by, /, we see the following below.


am335x-boneblack.dts root node model and compatible properties


We see that the model is the "TI AM335X BeagleBone Black"

Now we look at the compatible property and we see a list of strings.

The first is "ti,am335x-bone-black". This is the driver which would be the most specific to our device model. Therefore, we specify it first. Remember, most specific to more general.

Next on the list is "ti,am335x-bone". If the driver for the first device is not found, the operating system will search for the driver to this device.

Next on the list, even more general is "ti,am33xx". This is more general but will still work for our device model, which is the TI AM335x BeagleBone Black.

So basically, the first option, "ti,am335x-bone-black" is the exact compatible name of the board for the kernel to support it. The second option, "ti,am335x-bone" is also compatbile with the kernel which supports bone devices based on am335x, if the kernel doesn't support the previous exact model. The third option, "ti,am33xx" is also compatbile with the kernel which supports only am33xx soc based board, if the kernel doesn't support the previous options.

The root compatible property is used for machine identification.

The machine identification fails when none of these string values matches with the kernel supported compatible identification string list.

So the machine identification is what you see above.

Now go to Linux/arch/arm/boot/dts/am335x-bone-common.dtsi

Go down to where you see the definition for the i2c0 controller device node.

This is shown below.


am335x-bone-common.dtsi i2c0 controller device node in linux


tps and baseboard_eeprom are child nodes of the i2c0 device node, meaning they are connected to this node. The tps (which is a power management chip) is connected at i2c address 0x24. The baseboard_eeprom is connected at i2c address 0x50.

Once this i2c0 device node gets initialized by its driver, the basedboard_eeprom gets initialized by its driver. You can see that the baseboard_eeprom child node has a compatible property, which is, "atmel,24c256". This means that this device node will be taken care of by this driver.

This can be found at linux/drivers/misc/eeprom/at24.c

So you can see how root node compatible properties allow for machine identification, while (non-root) device node compatible properties allow for matching and loading of the appropriate driver for the device node such as for an i2c device node.



Related Resources





HTML Comment Box is loading comments...