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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120601204052.GB4258@opensource.wolfsonmicro.com>
Date:	Fri, 1 Jun 2012 21:40:53 +0100
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 Fri, Jun 01, 2012 at 01:23:24PM -0600, Stephen Warren wrote:

> However, Mark warned that changing this would be a bit painful because
> there are already users of the existing scheme. It looks like that's
> only tps65910 (which we haven't started using yet), db8500, and ab8500,
> so probably not that big a deal.

No, there's a bunch of others - some queued for -next, others open
coding the same scheme.  Any device with more than one regulator in a
node should be using the same scheme.

> We could either augment struct of_regulator_match with an integer ID
> field for each regulator (which would perhaps make it slightly painful
> to write the nodes and keep the IDs matched up), or add a new property

No, that's awful.  How's anyone supposed to read stuff like that?  The
interrupt bindings are a disaster, not a model.

> to each regulator provider node e.g. regulator-id which contained the
> name that the regulator driver knows the regulator as (which would match
> struct of_regulator_match.name), since the existing regulator-name
> property is used for semantically different purposes.

Oh, ick.  This isn't nice.  If anything I'd be more inclined to put a
named property in there and have drivers look for its presence.  The
presence of multiple name properties isn't nice.

> > 		vdd1_reg: regulator@0 {

Can't we use the right hand side of this?  It appears to just be
syntactic sugar without any current meaning.

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