linux-kernel - Re: [RFC 1/4] regulator: lp87565: enable voltage regardless of ENx pin

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]

Date:   Thu, 4 Jun 2020 12:07:59 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Luca Ceresoli <luca@...aceresoli.net>
Cc:     Liam Girdwood <lgirdwood@...il.com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Lee Jones <lee.jones@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, Keerthy <j-keerthy@...com>,
        Axel Lin <axel.lin@...ics.com>
Subject: Re: [RFC 1/4] regulator: lp87565: enable voltage regardless of ENx
 pin

On Wed, Jun 03, 2020 at 10:03:16PM +0200, Luca Ceresoli wrote:

> I suspect the only solution that allows to configure the EN_PIN_CTRLn bits
> correctly in all the possible hardware setups would be to tell in device
> tree / board info whether each enable pin is connected or not (which is a
> hardware _fact_) and which ENx pin should control which regulator output
> (which is a policy). But it would make this simple driver considerably more
> complex.

> Any suggestion about the correct way to handle this situation would be
> greatly appreciated.

We can tell if we've got a software controlled GPIO connected, if we
have then we should ensure that it continues to take effect.  That
should just be a single register write at startup from the sounds of it.
Otherwise yeah, just ignoring that there's a possibility of a GPIO we
don't know about seems sensible.

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