From: Keerthy <a0393675@ti.com>
To: Mark Brown <broonie@kernel.org>, Keerthy <j-keerthy@ti.com>
Cc: <lgirdwood@gmail.com>, <lee.jones@linaro.org>,
<linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<devicetree@vger.kernel.org>, <robh+dt@kernel.org>,
<mark.rutland@arm.com>
Subject: Re: [PATCH 3/3] regulator: lp873x: Add support for lp873x PMIC regulators
Date: Fri, 6 May 2016 10:13:24 +0530 [thread overview]
Message-ID: <572C20EC.7000706@ti.com> (raw)
In-Reply-To: <20160505153820.GF6292@sirena.org.uk>
Hi Mark,
On Thursday 05 May 2016 09:08 PM, Mark Brown wrote:
> On Thu, May 05, 2016 at 10:40:40AM +0530, Keerthy wrote:
>
>> +static const struct of_device_id of_lp873x_match_tbl[] = {
>> + { .compatible = "ti,lp8733-regulators",},
>> + { .compatible = "ti,lp8732-regulators",},
>> + { .compatible = "ti,lp873x-regulators",},
>> + {},
>> +};
>
> There should be no need for compatible strings here, we already know
> what device this is from the parent. The way we split drivers up for
> Linux is something that's internal to Linux and shouldn't be in the
> device tree. If we do have explicit compatible strings then they should
> (as always) be specific to a device, no wildcards.
Thanks for the review.
I am using of_platform_populate function in the mfd driver to create
platform devices for the child nodes, in my case regulators.
of_platform_populate in turn calls on to of_platform_bus_create which
mandates compatible properties. It quietly skips device creation if
there are no compatible properties.
When i enabled a debug print, i see this:
skipping /ocp/i2c@48070000/lp8732@61/regulators, no compatible prop
Hence i kept the compatible properties.
The driver supports two variants of LP873x family:
1) LP8732
2) LP8733
I will knock off the ti,lp873x-regulators compatible which is more
generic/wildcard entry.
Let me know if this approach is fine.
>
> Otherwise this looks sensible.
>
next prev parent reply other threads:[~2016-05-06 4:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 5:10 [PATCH 0/3] mfd: lp873x: Add lp873x PMIC support Keerthy
2016-05-05 5:10 ` [PATCH 1/3] Documentation: mfd/regulator: LP873X: Add information for the mfd and regulator drivers Keerthy
2016-05-05 5:10 ` [PATCH] mfd: lp873x: Add lp873x PMIC support Keerthy
2016-05-05 8:35 ` Manish Badarkhe
2016-05-06 4:08 ` Keerthy
2016-05-05 5:10 ` [PATCH 3/3] regulator: lp873x: Add support for lp873x PMIC regulators Keerthy
2016-05-05 15:38 ` Mark Brown
2016-05-06 4:43 ` Keerthy [this message]
2016-05-06 12:02 ` Mark Brown
2016-05-06 12:36 ` Keerthy
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=572C20EC.7000706@ti.com \
--to=a0393675@ti.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=j-keerthy@ti.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.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
Powered by JetHome