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 00:35:08 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	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 Wed, Jun 20, 2012 at 03:01:15PM -0600, Stephen Warren wrote:
> On 06/20/2012 02:40 PM, Arnd Bergmann wrote:

> > For a "compatible" property, I would expect two objects that have
> > the same register-level interface but are responsible for different
> > physical objects to have the same "compatible" values, but here
> > you specifically need distinct "regulator-compatible" values.

> I'd originally suggested "regulator-id" instead of
> "regulator-compatible" in order to avoid any association with the
> pre-existing "compatible" property. Mark didn't like that, although I
> don't think I quite understood why.

Like I said we already have names (and we have IDs inside the API as
well) and it also seems better to make the "which thing is this?"
property have the same name as the more generic "which thing is this?"
property.  I did mention the fact that drivers could read additional
properties to further identify the regulator if they were so moved.

Ideally we'd just be able to have either named nodes directly in the
parent or be able to have arrays function as a hash, really this is
trying to simulate a hash.

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

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