linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
	grant.likely@secretlab.ca, rob.herring@calxeda.com,
	arnd@arndb.de, linus.walleij@linaro.org, lrg@ti.com,
	lee.jones@linaro.org, devicetree-discuss@lists.ozlabs.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 2/3] regulator: dt: add policy to have property "regulator-compatible"
Date: Tue, 19 Jun 2012 12:03:27 -0600	[thread overview]
Message-ID: <4FE0BEEF.4060100@wwwdotorg.org> (raw)
In-Reply-To: <20120619175354.GO3974@opensource.wolfsonmicro.com>

On 06/19/2012 11:53 AM, Mark Brown wrote:
> On Tue, Jun 19, 2012 at 11:43:56AM -0600, Stephen Warren wrote:
>> On 06/19/2012 08:28 AM, Laxman Dewangan wrote:
> 
>>> +  The regulator is matched with the regulator-compatible.
> 
>> That last sentence should be true for any chip containing
>> multiple regulators and using the standard regulator binding. As
>> such, shouldn't that property be part of regulator.txt, rather
>> than each individual regulator chip's binding document?
> 
> No, there's more than one way to skin this cat.  We can either
> have something like this where there's a single DT node for all
> regulators on the device or we can have an MFD where the regulators
> all appear separately.  This is certainly what the former case
> should be using but it's less clear for the latter.

Well, I expected the language to be something along the lines of:

Optional properties:
...
- regulator-compatible: If a regulator chip contains multiple
regulators, and if the chip's binding contains a child node that
describes each regulator, then this property indicates which regulator
this child node is intended to configure.

... although I guess you'd need something to differentiate the
MFD-style vs. plain initdata-style mechanisms

So while as you say regulator.txt might not mandate that this be the
only method of handling multiple child nodes, shouldn't it document
this method as /a/ method in a central location to avoid all the
bindings that make use of this feature from duplicating the documentation?

  reply	other threads:[~2012-06-19 18:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19 14:28 [PATCH V2 0/3] regulator: dt: add policy to match regulator with prop "regulator-compatible" Laxman Dewangan
2012-06-19 14:28 ` [PATCH V2 1/3] regulator: dt: regulator match by regulator-compatible Laxman Dewangan
2012-06-19 17:39   ` Stephen Warren
2012-06-19 14:28 ` [PATCH V2 2/3] regulator: dt: add policy to have property "regulator-compatible" Laxman Dewangan
2012-06-19 17:43   ` Stephen Warren
2012-06-19 17:53     ` Mark Brown
2012-06-19 18:03       ` Stephen Warren [this message]
2012-06-19 18:06         ` Mark Brown
2012-06-19 14:28 ` [PATCH V2 3/3] ARM: dts: db8500: add node property "regulator-compatible" regulator node Laxman Dewangan
2012-06-19 16:13   ` Lee Jones
2012-06-19 17:32     ` Stephen Warren
2012-06-20  7:09       ` Lee Jones
2012-06-20  7:39         ` Laxman Dewangan
2012-06-20  8:01           ` Lee Jones
2012-06-20  8:19             ` Laxman Dewangan
2012-06-20  8:56               ` Lee Jones
2012-06-20 10:06                 ` Mark Brown
2012-06-20 11:25                   ` Lee Jones
2012-06-20 11:27                     ` Laxman Dewangan
2012-06-20 11:37                       ` Lee Jones
2012-06-20 16:14         ` Stephen Warren
2012-06-19 17:29   ` Stephen Warren
2012-06-20  8:59 ` [PATCH V2 0/3] regulator: dt: add policy to match regulator with prop "regulator-compatible" Linus Walleij
2012-06-20 10:00   ` Mark Brown
2012-06-20 16:23     ` Stephen Warren
2012-06-21  8:02       ` Linus Walleij
2012-06-21  9:53       ` Mark Brown

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=4FE0BEEF.4060100@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=ldewangan@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=rob.herring@calxeda.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 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).