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

Powered by blists - more mailing lists