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

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: <AM5PR1001MB099460B2D291644F088707BA80500@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
Date:   Tue, 17 Dec 2019 09:53:52 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Marco Felsch <m.felsch@...gutronix.de>,
        Adam Thomson <Adam.Thomson.Opensource@...semi.com>
CC:     Mark Brown <broonie@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Support Opensource <Support.Opensource@...semi.com>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "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>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "joel@....id.au" <joel@....id.au>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "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 17 December 2019 09:01, Marco Felsch wrote:

> > > 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.
> 
> I see, so we have to guarantee that the requested gpio is configured as
> input. This can be done by:

This is one of the reasons I thought this was better suited to being done in the
pinctrl/pinmux side. If you configure the GPIO as for regulator control then
the code can automatically configure the GPIO for input. That doesn't then need
to be in the regulator driver.

But yes we wouldn't really want to configure a regulator to be controlled via a
GPI when it's configured as a GPO as it makes no sense.

> 
>   if (gpi->flags & FLAG_IS_OUT)
>   	return -EINVAL;
> 
> Regards,
>   Marco