From: Grant Likely <grant.likely@secretlab.ca>
To: Viresh Kumar <viresh.kumar@linaro.org>, Lee Jones <lee.jones@linaro.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
rabin.vincent@stericsson.com, shiraz.hashim@st.com,
devicetree-discuss@lists.ozlabs.org,
linux-kernel@vger.kernel.org, spear-devel@list.st.com,
linus.walleij@linaro.org,
Vipul Kumar Samar <vipulkumar.samar@st.com>
Subject: Re: [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver
Date: Wed, 05 Dec 2012 22:42:03 +0000 [thread overview]
Message-ID: <20121205224203.691153E0E22@localhost> (raw)
In-Reply-To: <CAKohpokLVEH+4F_VXh5auUm48cWWe0mumZME8yOCcAezcwJbCQ@mail.gmail.com>
On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 30 November 2012 21:15, Lee Jones <lee.jones@linaro.org> wrote:
> > But ... I don't see how the changes in the -i2c and -spi files
> > are of benefit either. When I boot without the ID table I still
> > get "stmpe-i2c 0-0040: stmpe1601 detected, chip id: 0x212".
> >
> > What is it that actually uses the IDs?
> >
> > Perhaps Viresh can shine some light on the matter?
>
> As you can see, i wasn't the author of this patch and when you asked
> this question, i didn't had an answer to it. I went through code and
> formed some theory/story :) .
>
> @Grant: i need your help to check if my theory is correct or not. Question
> is about adding below code in any i2c client driver:
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id stmpe_dt_ids[] = {
> + { .compatible = "st,stmpe610", .data = &stmpe_i2c_id[0], },
> + { .compatible = "st,stmpe801", .data = &stmpe_i2c_id[1], },
> + { .compatible = "st,stmpe811", .data = &stmpe_i2c_id[2], },
> + { .compatible = "st,stmpe1601", .data = &stmpe_i2c_id[3], },
> + { .compatible = "st,stmpe2401", .data = &stmpe_i2c_id[4], },
> + { .compatible = "st,stmpe2403", .data = &stmpe_i2c_id[5], },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, stmpe_dt_ids);
> +#endif
> +
> static struct i2c_driver stmpe_i2c_driver = {
> .driver = {
> .name = "stmpe-i2c",
> @@ -88,6 +102,7 @@ static struct i2c_driver stmpe_i2c_driver = {
> #ifdef CONFIG_PM
> .pm = &stmpe_dev_pm_ops,
> #endif
> + .of_match_table = of_match_ptr(stmpe_dt_ids),
>
> So, what is the use of this table when we already have i2c_driver.id_table
> populated.
>
> This is my theory:
> ---------------------
> Adapter drivers supporting DT will call:
> of_i2c_register_devices()
> {
> for_each_child_of_node(adap->dev.of_node, node) {
> if (of_modalias_node(node, info.type, sizeof(info.type)) < 0)
> error condition
>
> ...
> result = i2c_new_device(adap, &info);
>
> ...
> }
>
> of_modalias_node(): expects compatible in child node, i.e. stmpe node in our
> case. If it is not there, then that node is skipped. then it copies
> string after ','
> to info.type. So, for us only "stmpe810" out of "st,stmpe810" is copied.
>
> Now this name, i.e. "stmpe810" is copied as client.name in i2c_new_device()
> and device_register() is called, which will eventually call:
>
> i2c_device_match()
> {
> /* Attempt an OF style match */
> if (of_driver_match_device(dev, drv))
> return 1;
>
> driver = to_i2c_driver(drv);
> /* match on an id table if there is one */
> if (driver->id_table)
> return i2c_match_id(driver->id_table, client) != NULL;
> }
>
> This first tries to match the table my patch added, _BUT_ the string will
> never match as we had "st,stmpe810" in table and "stmpe810" in dev.
of_driver_match_device() matches against the compatible list in
dev->of_node, not against the device name. So, if the compatible
property has a string that is in the table, then it really should match
against it.
>
> So, we fall back to i2c_match_id(), which will match it against
> i2c_driver.id_table present in driver, which has entry for "stmpe810" and
> so strings matched.
>
> @Lee: This is what happened in your case. :)
>
> So, whether its DT or non DT, true is returned from here if something
> matched.
>
> Later on, this will be called:
>
> static int i2c_device_probe(struct device *dev)
> {
> .....
> status = driver->probe(client, i2c_match_id(driver->id_table, client));
Here things are a bit wonky. Even if matched against the table, it is
possible that it also matches against i2c_match_id() and that data is
passed to the driver.
But regardless, it is the responsiblity of the probe function to go and
look if of_driver_match_device() matches against anything if it cares
about the of_match_table entries (for instance, if there is extra data
attached).
> ....
> }
>
> Which will again match the legacy table to find correct struct i2c_device_id *id
> to pass to probe().
>
> So, the final question: WTF is of_match_table for?
A bit of history is valuable here. The whole of_modalias_node() thing is
really just a best-effort heuristic for figuring out which driver
*might* work against a device described in the device tree. It won't
work in all circumstances (and it was created at a time when there was
resistance to adding DT knowledge to drivers). An of_match_table is the
robust way of identifying specific devices and allows for matching
against any entry in the compatible list.
g.
next prev parent reply other threads:[~2012-12-05 22:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-29 14:40 [PATCH V5 1/2] mfd: stmpe: Get rid of irq_invert_polarity Viresh Kumar
[not found] ` <2dcd7cb4c4022fa24b5328974e4226f5aaf89419.1354199865.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-11-29 14:40 ` [PATCH V5 2/2] mfd: stmpe: Update DT support in stmpe driver Viresh Kumar
[not found] ` <121653def4e985b0c1b59045637dd4518f97e73a.1354199865.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-11-30 10:57 ` Samuel Ortiz
2012-11-30 12:45 ` Lee Jones
2012-11-30 13:11 ` Viresh Kumar
2012-11-30 13:20 ` Lee Jones
[not found] ` <20121130132036.GA23648-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-30 13:44 ` Viresh Kumar
2012-11-30 15:45 ` Lee Jones
2012-11-30 19:03 ` Viresh Kumar
2012-12-05 13:03 ` Viresh Kumar
2012-12-05 13:19 ` Lee Jones
2012-12-05 13:24 ` Viresh Kumar
2012-12-05 22:42 ` Grant Likely [this message]
2012-12-06 1:58 ` Viresh Kumar
2012-12-06 9:50 ` Lee Jones
[not found] ` <20121206095019.GN2718-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-06 9:56 ` Viresh Kumar
[not found] ` <CAKohpokNQB6L2vvjmvA7_3KomFXnV9wZ-uBjrfRVuBL=QWgr_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-06 10:11 ` Lee Jones
2012-12-06 10:19 ` Viresh Kumar
2012-12-06 10:35 ` Lee Jones
2012-12-06 10:42 ` Viresh Kumar
2012-12-06 11:12 ` Lee Jones
2012-12-06 11:19 ` Viresh Kumar
[not found] ` <CAKohponrZ8a+=ozXox60nRVBO174Nr=GoSjKkkz7KjLCxd5BhQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-12-06 11:33 ` Lee Jones
2012-12-07 13:37 ` Grant Likely
2012-12-06 2:36 ` Viresh Kumar
2012-12-07 13:44 ` Grant Likely
2012-12-01 16:49 ` [PATCH V5 1/2] mfd: stmpe: Get rid of irq_invert_polarity Linus Walleij
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=20121205224203.691153E0E22@localhost \
--to=grant.likely@secretlab.ca \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rabin.vincent@stericsson.com \
--cc=sameo@linux.intel.com \
--cc=shiraz.hashim@st.com \
--cc=spear-devel@list.st.com \
--cc=vipulkumar.samar@st.com \
--cc=viresh.kumar@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).