linux-kernel - RE: [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage selection documentation

Open Source and information security mailing list archives

Message-ID: <AM5PR1001MB09941005A47B603805D3C53280510@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
Date:   Mon, 16 Dec 2019 16:32:48 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Marco Felsch <m.felsch@...gutronix.de>,
        Mark Brown <broonie@...nel.org>
CC:     "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Support Opensource <Support.Opensource@...semi.com>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "andrew@...id.au" <andrew@...id.au>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "joel@....id.au" <joel@....id.au>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v3 3/6] dt-bindings: mfd: da9062: add regulator voltage
 selection documentation

On 16 December 2019 08:55, Marco Felsch wrote:

> On 19-12-12 16:51, Mark Brown wrote:
> > On Thu, Dec 12, 2019 at 05:21:53PM +0100, Marco Felsch wrote:
> >
> > > "... what's driving the input ..":
> > > Sorry I didn't get you here. What did you mean? The input is driven by
> > > the host. This can be any gpio line and in my case it is a gpio line
> > > driven by the soc-hw during a suspend operation.
> >
> > Something needs to say what that thing is, especially if it's runtime
> > controllable.  In your case from the point of view of software there is
> > actually no enable control so we shouldn't be providing an enable
> > operation to the framework.
> 
> The enabel control signal is always available, please check [1] table
> 63. There is a mux in front of the enable pin so:
> 
>              +-------------
>  Seq. |\     |   Regulator
>  GPI1 | \    |
>  GPI2 | | -- > Enable
>  GPI3 | /    |
>       |/     .
>              .
>              .
> 
> Adam please correct me if this is wrong.

Yes the register can always be configured regardless of the associated pin
configuration, but if say GPIO1 was configured as a GPO but a regulator was
configured to use GPIO1 as its GPI control mechanism, the output signal from
GPIO1 would be ignored, the sequencer control would not have any effect and
you're simply left with manual I2C control. Really we shouldn't be getting into
that situation though. If a GPIO is to be used as a regulator control signal
then it should be marked as such and I don't think we should be able to use that
pin for anything other than regulator control.

> 
> [1] https://www.dialog-
> semiconductor.com/sites/default/files/da9062_datasheet_3v6.pdf
> 
> Regards,
>   Marco
> 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@...ts.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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