linux-kernel - Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Jun 2012 09:56:14 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Laxman Dewangan <ldewangan@...dia.com>,
	"olof@...om.net" <olof@...om.net>,
	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>
Subject: Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911

On 06/10/2012 08:57 PM, Mark Brown wrote:
> On Fri, Jun 08, 2012 at 10:24:06PM -0600, Stephen Warren wrote:
>> On 06/08/2012 09:06 PM, Mark Brown wrote:
> 
>>> If we're going to do this we need to update all the existing DT bindings
>>> for drivers that use single node regulators like this.  Please also
>>> change the name used for the property to regulator-compatible to make it
>>> clear that the idea is the same as normal compatible properties.
> 
>> I'm not sure of the logic behind naming the property
>> "regulator-compatible"; the standard compatible property identifies that
>> the node is of a particular type/class, whereas the regulator-id in the
>> example Laxman quoted would indicate the specific identity/object. Those
>> seem like different things.
> 
> They're both doing the same thing - up until you get the second register
> compatible device a compatible binding is referencing a specific thing
> too.  It's just saying "handle this like an X".

I believe there's a big semantic difference here.

For every node with compatible="foo", you find a driver for "foo" and
instantiate it. This will work for any number of nodes with that
compatible value. The nodes are completely independent and there are no
particular requirements re: what the parent of those nodes are, beyond
being a bus of an appropriate type such as any old I2C bus.

However, with the regulator identifiers, it's almost exactly the opposite:

* There's no generic "search all busses in the system for this regulator
type", but rather once a particular type of regulator chip gets
instantiated, that chip's HW design defines which specific regulators it
contains, and nodes for those regulators may exist as children of the
regulator chip itself, and nowhere else. The individual driver is then
going to look for child nodes with specific
regulator-id/regulator-compatible values, not some arbitrary centralized
table of possible values.

* Each regulator-id/regulator-compatible value identifies a specific
individual regulator within the chip that contains it. There is only one
of each named regulator, since that's what exists in HW. So, this is
about configuring HW that we know exists (because it's part of the HW
represented by the parent node for the chip) rather than defining which
HW is present on unprobeable busses, as the device-level compatible does.

Given those differences, I really think that using "compatible" in the
name of the property is just going to cause confusion.
--
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/