linux-kernel - Re: [PATCH v4 3/7] [media] ad5820: DT new optional field enable-gpios

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: <CAL_JsqLM9E45nvSToQV=XDwTmppkYcsPd-Ddzy+AJ8GP==aL+A@mail.gmail.com>
Date:   Mon, 1 Oct 2018 07:36:22 -0500
From:   Rob Herring <robh@...nel.org>
To:     Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Cc:     Pavel Machek <pavel@....cz>, Sakari Ailus <sakari.ailus@....fi>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Hans Verkuil <hans.verkuil@...co.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v4 3/7] [media] ad5820: DT new optional field enable-gpios

On Mon, Oct 1, 2018 at 3:20 AM Ricardo Ribalda Delgado
<ricardo.ribalda@...il.com> wrote:
>
> Hi Rob
> On Thu, Sep 27, 2018 at 8:23 PM Rob Herring <robh@...nel.org> wrote:
> >
> > On Thu, Sep 20, 2018 at 10:47:47PM +0200, Ricardo Ribalda Delgado wrote:
> > > Document new enable-gpio field. It can be used to disable the part
> >
> > enable-gpios
> >
> > > without turning down its regulator.
> > >
> > > Cc: devicetree@...r.kernel.org
> > > Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
> > > Acked-by: Pavel Machek <pavel@....cz>
> > > ---
> > >  Documentation/devicetree/bindings/media/i2c/ad5820.txt | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/i2c/ad5820.txt b/Documentation/devicetree/bindings/media/i2c/ad5820.txt
> > > index 5940ca11c021..9ccd96d3d5f0 100644
> > > --- a/Documentation/devicetree/bindings/media/i2c/ad5820.txt
> > > +++ b/Documentation/devicetree/bindings/media/i2c/ad5820.txt
> > > @@ -8,6 +8,12 @@ Required Properties:
> > >
> > >    - VANA-supply: supply of voltage for VANA pin
> > >
> > > +Optional properties:
> > > +
> > > +   - enable-gpios : GPIO spec for the XSHUTDOWN pin. Note that the polarity of
> > > +the enable GPIO is the opposite of the XSHUTDOWN pin (asserting the enable
> > > +GPIO deasserts the XSHUTDOWN signal and vice versa).
> >
> > shutdown-gpios is also standard and seems like it would make more sense
> > here. Yes, it is a bit redundant to have both, but things just evolved
> > that way and we don't want to totally abandon the hardware names (just
> > all the variants).
> >
>
> Sorry to insist
>
> The pin is called xshutdown, not shutdown and is inverse logic,
> Wouldnt it make more sense to use the name
> enable-gpios?

Inverse of what? shutdown-gpios is the inverse of enable-gpios. By
using shutdown-gpios you can just get rid of "Note that the polarity
of the enable GPIO is the opposite of the XSHUTDOWN pin (asserting the
enable GPIO deasserts the XSHUTDOWN signal and vice versa)."

This looks to me like a case of just standardizing the name so for
example we just have "reset" instead of many flavors like rst, RSTb,
RESETb, RESETn, nRESET, etc.

Rob