linux-kernel - Re: [PATCH 3/4] devicetree: add a binding for a group of regulator

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, 24 Nov 2014 17:55:16 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Alban Bedel <alban.bedel@...onic-design.de>
Cc:	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	Grant Likely <grant.likely@...aro.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Kumar Gala <galak@...eaurora.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH 3/4] devicetree: add a binding for a group of regulator

On Mon, Nov 24, 2014 at 06:32:04PM +0100, Alban Bedel wrote:

> Honestly my primary aim wasn't the sequencing, but rather to increase
> the usefulness of generic drivers. Generic driver generally only
> manipulate a single supply, however many hardware might have more,
> and won't need any specific power up ordering. Having to write a full
> new driver just because of an extra supply doesn't seems to make much
> sense to me.

I'm having a really hard time following the above - you say "generic
driver generally only manipulate a single supply" but that's absolutely
not the case.  A driver should control exactly as many supplies as the
device it is controlling does.  

The nearest I can get to something that I think I can understand is a
device variant that has some changes in supplies but varaints aren't
something that we need to write entirely new drivers for, just new
device IDs and a few lines of conditional code.

It's possible that I'm missing something but I'm really struggling to
see the problem that you're trying to solve here or why this is an
abstraction that makes sense.

> As alternative solution to this problem I though about allowing a list
> of regulator for the supplies:

>  vin-supply = <&reg1>, <&reg2>;

> The API could still return a single consumer but it would operate on
> all the regulators in the list instead of just one. Would that be a
> better solution?

No, that's even worse - this is just hacking around whatever problem
you're facing.  The device tree should accurately describe the hardware
not some random thing that vaguely looks like the hardware because it
happens to let us shoehorn things onto it.

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