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 for Android: free password hash cracker in your pocket

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

Message-ID: <20120611162040.GB4194@opensource.wolfsonmicro.com>
Date:	Tue, 12 Jun 2012 00:20:41 +0800
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Stephen Warren <swarren@...dotorg.org>
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 Mon, Jun 11, 2012 at 09:56:14AM -0600, Stephen Warren wrote:

> * 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.

This doesn't seem terribly different to me especially in some of the
cases people want to use this for where we try to describe the
subfunctions of the chip using this mechanism.  You have a fixed set of
regulators that might exist in a superset device (possibly with some
incompatibilities, or with additional properties providing more data on
the hardware) and then you mix and match what's in the system based
on the nodes you register for the subset device you're using.  This sort
of thing is actually much more idiomatic with DT than it is with
platform data (look at how people want to put device nodes in for the
MFD subfunctions all the time...).

Really all compatible is saying to me is "here's how you understand
this, handle it like an X" and this feels exactly the same.

Of course, if someone could just fix the DT to actually be able to do
key/value pairs, or allow us to do something useful with the
"regulator" string we need to put in there...

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)