linux-kernel - Re: Question about fixed regulator DT properties

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:	Wed, 26 Nov 2014 19:20:21 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Question about fixed regulator DT properties

On Wed, Nov 26, 2014 at 09:13:50PM +0200, Vladimir Zapolskiy wrote:

> If I want to enable a fixed regulator (not controlled by
> bootloader/firmware) by Linux on boot or when fixed.ko module is bound,
> shall I specify the same "regulator-boot-on" property? At least this is
> the practical way to enable a fixed and/or gpio regulator right now, but
> is it correct?

It depends what you're trying to accomplish by doing this.

> Or should the regulator always be enabled externally (assuming
> "regulator-always-on" is omitted) after registration independently on
> "regulator-boot-on" property?

Best practice is that there should be a consumer which keeps the
regulator enabled whenever it is required.  There should normally be
little use for boot-on, it's mostly there to ease handover from the
bootloader in cases where we can't read the hardware state - if you're
not sure if you should use it the chances are you shouldn't.

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