linux-kernel - Re: [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible

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:	Thu, 21 Jun 2012 14:50:35 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	Laxman Dewangan <ldewangan@...dia.com>, lrg@...com,
	rob.herring@...xeda.com, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, lee.jones@...aro.org,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 2/3] regulator: dt: regulator match by regulator-compatible

On Wednesday 20 June 2012, Mark Brown wrote:
> On Wed, Jun 20, 2012 at 03:01:15PM -0600, Stephen Warren wrote:
> > The problem is that dtc has no named constants. Using raw integers
> > instead of names would make the .dts file rather unreadable. The issue
> > is much more accute for regulators than say GPIOs or IRQs because
> > there's likely no relative order to the set of regulators defined by the
> > documentation, unlike for GPIOs/IRQs where the integer (often) is the
> > object's primary ID.
> 
> Well, there are actually a lot of chips which do provide useful indexes
> - for example the wm831x devices just have a bunch of DCDCs and a bunch
> of LDOs which can usefully be referred to as DCDCn or LDOn.  They will
> hopefully not need to use this interface.  It's just that there's also a
> large class of devices we need to cater for which don't have any such
> regularity in their register map, this biding
> mechanism is for them.

Ok, now it all makes sense. Thanks for bearing with me being a little
slow on this topic.

It seems that the drivers that are changed to use this could also try to
describe the individual regulators completely, by moving the contents
of e.g. ab8500_regulator_info into the device tree, but having the string
identifier with an in-kernel table makes sense when there is only one
such table.

	Arnd

--
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/