Message-ID: <CAOesGMgYAR938F8PnVWaymzMBQwDKeAiUgEP81bv2nN14NmLGg@mail.gmail.com>
Date:	Sat, 2 Jun 2012 14:19:57 -0700
From:	Olof Johansson <olof@...om.net>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Laxman Dewangan <ldewangan@...dia.com>,
	Stephen Warren <swarren@...dia.com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	devicetree-discuss@...ts.ozlabs.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>
Subject: Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911

[+devicetree-discuss and grant/rob]

On Fri, Jun 1, 2012 at 2:04 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Fri, Jun 01, 2012 at 02:44:00PM -0600, Stephen Warren wrote:
>
>> Could you expand on "named property" a bit; I'm not quite sure what
>> you're getting at - literally a property with name "named" (which
>> would be the same as regulator-id under just a different property
>> name), or ...?
>
> Just a property where we only care about a name (ie, that the property
> is present).
>
>> > Can't we use the right hand side of this?  It appears to just be
>> > syntactic sugar without any current meaning.
>
>> The stuff to the right of @ is the "unit address" and must match the
>> value in the reg property. Using that was the first proposal I had
>> above (which I also didn't like as much)
>
> The stuff to the left of the @ is just noise right now, though - it has
> no meaning currently.  It's filled in with "regulator" because we need
> to put something there AFAICT.

Right. In general (and historically) in the device tree, names of the
nodes should have meaning for the person reading the device tree, but
it's not meant to be used for software to figure out the hardware
configuration -- that should instead be handled through compatible +
other properties.

Names are generally kept fairly generic (ethernet, cpus, memory, pci, etc).

Where it starts to become gray area is when it comes down to specific
bindings, and essentially the device nodes underneath of those
devices. It's been generally accepted that we can put meaning to the
names there if needed, but it's still better to avoid it.

I was originally OK with the regulator binding where names have
meaning, but after having looked at it a bit recently when looking at
bindings for some new boards we have, I realized that the original
suggestion for regulator bindings doesn't necessarily isolate the
naming dependencies to only be under the regulators in question. In
particular, for things such as fixed regulators, they can be located
at other places in the device tree.

Maybe the solution to that case is to just aggregate them in one place
and make a pseudo-binding for that (or those, in case of multiple
locations).

On the rest of the name-has-meaning discussion, I think it would be
cleaner to move away from it now while there's relatively few users of
it (with a migratin path), rather than revise it later. But I'll leave
it to Grant and Rob to decide which way the prefer things to be. I
think they might both be travelling around LC/LinuxCon events at the
moment though.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists