Search code examples
linux-kernellinux-device-driverembedded-linuxdevice-tree

device-tree overlay: fragment numbers


Consider the following device-tree overlay example. The fragments are numbered 0, 1, 2.

Do the numbers matter? Do they have to be in ascending order? Or would 0, 2, 1 also work? Where is it specified?

/dts-v1/;
/plugin/;

/ {
    fragment@0 {
        target = <&foo>;
        __overlay__ {
            ...
        };
    };

    fragment@1 {
        target = <&bar>;
        __overlay__ {
            ...
        };
    };

    fragment@2 {
        target = <&baz>;
        __overlay__ {
            ...
        };
    };

};

Solution

  • Those numbers (and names) don't matter. Take a look at next functions in drivers/of/overlay.c:

    of_overlay_create() -> of_build_overlay_info() -> of_fill_overlay_info() -> find_target_node()

    As you can see, the code just iterates over the tree (using for_each_child_of_node()) and then obtaining node of interest by "__overlay__" name, like this:

    ovinfo->overlay = of_get_child_by_name(info_node, "__overlay__");
    

    So those fragments are just some nodes, and their names don't matter. The only thing really used is content of those nodes.

    I can even suppose that you can completely omit those @1, @2 postfixes. Take a look at Device Tree specification (section 2.2.1 Node Names):

    Each node in the device tree is named according to the following convention:

    node-name@unit-address

    The unit-address component of the name is specific to the bus type on which the node sits. It consists of one or more ASCII characters from the set of characters in Table 2-1. The unit-address must match the first address specified in the reg property of the node. If the node has no reg property, the @ and unit-address must be omitted and the node-name alone differentiates the node from other nodes at the same level in the tree. The binding for a particular bus may specify additional, more specific requirements for the format of reg and the unit-address.

    Of course, there can be some tricks in code that parses device tree file, like this: drivers/of/fdt.c, unflatten_dt_node():

    if ((*p1) == '@')
    

    But I really doubt it that the number after '@' means something (in your case).