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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <247eef95-9f7a-c1cd-245c-05304b02e4da@lucaceresoli.net>
Date:   Fri, 5 Jun 2020 09:57:09 +0200
From:   Luca Ceresoli <luca@...aceresoli.net>
To:     Mark Brown <broonie@...nel.org>
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

Hi Mark,

On 04/06/20 13:07, Mark Brown wrote:
> 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.

Ideally yes, but it would be made more complex by the chip flexibility:
it's possible to choose which enable pin should drive each output.

For example this configuration is supported by the chip:

- BUCK0 is on if EN_BUCK0 high AND pin EN0 is active
- BUCK1 is on if EN_BUCK1 high AND pin EN0 is active
- BUCK2 is on if EN_BUCK2 high AND pin EN1 is active
- BUCK3 is on if EN_BUCK3 high (no pin used)
- pin EN2 is used as a GPIO (LP875xx acts as an I2C GPIO expander)

So it would be absolutely OK to describe in DT that EN0 and EN1 connect
the SoC to the LP875xx and that EN2 is connected to something else.

But describing in DT the association between enable pins and buck
outputs would be more a configuration than hardware description IMO.

And I'm not even considering the case where the enable pins are be
connected to something else, out of the SoC control, but still meant to
be used to control the buck output.

> That
> should just be a single register write at startup from the sounds of it.

Exactly, each buck output has a register containing the bits involved in
this discussion.

> Otherwise yeah, just ignoring that there's a possibility of a GPIO we
> don't know about seems sensible.

Thanks,
-- 
Luca