Skip to contentSkip to conversation

DT: of_platform_populate Vs of_platform_bus_probe.

DISCUSSION Srinivas KANDAGATLA 2 participants 3 messages Oct 31, 2012 – Nov 1, 2012

lore
Share & tools
lore
#0 lore raw

Hi All,
I have few queries on of_platform_populate and of_platform_bus_probe functions.

Use-case is, I want to explicitly register platform devices from some nodes at post-core or late-init level(like child@1). And I don't want of_platform_populate to register platform devices for that node again, so I pass "simple-bus" in match-table. Problem is that exiting code for of_platform_populate probes it.

Looking at the function documentation, which states of_platform_bus_probe will only create children of the root which are selected by the @matches argument.

of_platform_populate walks the device tree and creates devices from nodes. It differs in that it follows the modern convention of requiring all device nodes to have a 'compatible' property, and it is suitable for creating devices which are children of the root node.

Lets say If we call of_platform_populate(NULL, match_table, NULL, NULL) on a device trees like the below with

struct of_device_id match_table[] = {
    { .compatible = "simple-bus", }
    {}
};
parent@0{
    compatible    = "xxx,parent1", "simple-bus";
    ...
    child@0 {
        compatible    = "xxx,child0", "simple-bus";
        ...
    };
    child@1 {
        compatible    = "xxx,child1";
        ...
    };
    child@2 {
        compatible    = "xxx,child2", "simple-bus";
        ...
    };
};

of_platform_bus_probe would create platform-devices for parent@0, child@0 and child@2
where as
of_platform_populate would create platform-devices for parent@0, child@0, child@1 and child@2 nodes.

So the question is
why do we need to have @matches argument to of_platform_populate in the first place, if it creates all the devices by walking the dt nodes?

It is bit confusing, As some platforms use of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL) assuming that only matching nodes will end up having platform device.
Also
some platforms use of_platform_bus_probe(NULL, match_table, NULL), where match table is of_default_bus_match_table.

Am not 100% sure what is the right solution, but I think lot of platforms would want behavior like of_platform_bus_probe which takes lookups aswell. If the suggestion is to use of_platform_bus_probe, Which I can't use as It does not take Auxdata(lookups).

Thanks,
srini

#1 lore raw
Quoted 23 lines · Srinivas KANDAGATLA

Hi All,
I have few queries on of_platform_populate and of_platform_bus_probe functions.

Use-case is, I want to explicitly register platform devices from some nodes at post-core or late-init level(like child@1). And I don't want of_platform_populate to register platform devices for that node again, so I pass "simple-bus" in match-table. Problem is that exiting code for of_platform_populate probes it.

Looking at the function documentation, which states of_platform_bus_probe will only create children of the root which are selected by the @matches argument.

of_platform_populate walks the device tree and creates devices from nodes. It differs in that it follows the modern convention of requiring all device nodes to have a 'compatible' property, and it is suitable for creating devices which are children of the root node.

Lets say If we call of_platform_populate(NULL, match_table, NULL, NULL) on a device trees like the below with

struct of_device_id match_table[] = {
    { .compatible = "simple-bus", }
    {}
};
Quoted 5 lines
parent@0{
    compatible    = "xxx,parent1", "simple-bus";
    ...
    child@0 {
        compatible    = "xxx,child0", "simple-bus";

Well simple-bus here is generally not right unless you want to create devices for children of child@0.

Quoted 18 lines
        ...
    };
    child@1 {
        compatible    = "xxx,child1";
        ...
    };
    child@2 {
        compatible    = "xxx,child2", "simple-bus";
        ...
    };
};

of_platform_bus_probe would create platform-devices for parent@0, child@0 and child@2
where as
of_platform_populate would create platform-devices for parent@0, child@0, child@1 and child@2 nodes.

Quoted 3 lines

So the question is
why do we need to have @matches argument to of_platform_populate in the first place, if it creates all the devices by walking the dt nodes?

The matches is for matching buses, not child devices. It is assumed you want to create devices for all 1st level children.

Quoted 6 lines

It is bit confusing, As some platforms use of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL) assuming that only matching nodes will end up having platform device.
Also
some platforms use of_platform_bus_probe(NULL, match_table, NULL), where match table is of_default_bus_match_table.

There should be no new users of of_platform_bus_probe. It is there for historical reasons on PPC.

Quoted 3 lines

Am not 100% sure what is the right solution, but I think lot of platforms would want behavior like of_platform_bus_probe which takes lookups aswell. If the suggestion is to use of_platform_bus_probe, Which I can't use as It does not take Auxdata(lookups).

of_platform_populate is what you should use.

Rob

#2 lore raw
Quoted 50 lines · Rob Herring
Quoted 23 lines · Srinivas KANDAGATLA

Hi All,
I have few queries on of_platform_populate and of_platform_bus_probe functions.

Use-case is, I want to explicitly register platform devices from some nodes at post-core or late-init level(like child@1). And I don't want of_platform_populate to register platform devices for that node again, so I pass "simple-bus" in match-table. Problem is that exiting code for of_platform_populate probes it.

Looking at the function documentation, which states of_platform_bus_probe will only create children of the root which are selected by the @matches argument.

of_platform_populate walks the device tree and creates devices from nodes. It differs in that it follows the modern convention of requiring all device nodes to have a 'compatible' property, and it is suitable for creating devices which are children of the root node.

Lets say If we call of_platform_populate(NULL, match_table, NULL, NULL) on a device trees like the below with

struct of_device_id match_table[] = {
    { .compatible = "simple-bus", }
    {}
};
Quoted 5 lines
parent@0{
    compatible    = "xxx,parent1", "simple-bus";
    ...
    child@0 {
        compatible    = "xxx,child0", "simple-bus";

Well simple-bus here is generally not right unless you want to create devices for children of child@0.

Quoted 18 lines
        ...
    };
    child@1 {
        compatible    = "xxx,child1";
        ...
    };
    child@2 {
        compatible    = "xxx,child2", "simple-bus";
        ...
    };
};

of_platform_bus_probe would create platform-devices for parent@0, child@0 and child@2
where as
of_platform_populate would create platform-devices for parent@0, child@0, child@1 and child@2 nodes.

Quoted 7 lines
Quoted 3 lines

So the question is
why do we need to have @matches argument to of_platform_populate in the first place, if it creates all the devices by walking the dt nodes?

The matches is for matching buses, not child devices.

It is assumed you
want to create devices for all 1st level children.

Thankyou Rob,
my issue solved with the above understanding.
I was creating device nodes without any parent, which is why of_platform_populate is probing them.

Quoted 16 lines
Quoted 6 lines

It is bit confusing, As some platforms use of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL) assuming that only matching nodes will end up having platform device.
Also
some platforms use of_platform_bus_probe(NULL, match_table, NULL), where match table is of_default_bus_match_table.

There should be no new users of of_platform_bus_probe. It is there for historical reasons on PPC.

Quoted 2 lines

Am not 100% sure what is the right solution, but I think lot of platforms would want behavior like of_platform_bus_probe which takes lookups aswell. If the suggestion is to use of_platform_bus_probe, Which I can't use as It does not take Auxdata(lookups).

of_platform_populate is what you should use.

Rob