All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
To: Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <robherring2@gmail.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>
Cc: "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>"linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: DT: of_platform_populate Vs of_platform_bus_probe.
Date: Wed, 31 Oct 2012 14:54:59 +0000	[thread overview]
Message-ID: <50913BC3.7090103@st.com> (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

WARNING: multiple messages have this Message-ID (diff)
From: Srinivas KANDAGATLA <srinivas.kandagatla@st.com>
To: Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <robherring2@gmail.com>,
	"devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: DT: of_platform_populate Vs of_platform_bus_probe.
Date: Wed, 31 Oct 2012 14:54:59 +0000	[thread overview]
Message-ID: <50913BC3.7090103@st.com> (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


             reply	other threads:[~2012-10-31 14:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31 14:54 Srinivas KANDAGATLA [this message]
2012-10-31 14:54 ` DT: of_platform_populate Vs of_platform_bus_probe Srinivas KANDAGATLA
2012-10-31 15:21 ` Rob Herring
2012-11-01 10:10   ` Srinivas KANDAGATLA

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50913BC3.7090103@st.com \
    --to=srinivas.kandagatla@st.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robherring2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.