linux-kernel - Re: [PATCH 5/5] iio: addac: ad74413r: add support for reset-gpio

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: <20221114194157.1d03588a@jic23-huawei>
Date:   Mon, 14 Nov 2022 19:41:57 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Cosmin Tanislav <cosmin.tanislav@...log.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Michael Hennerich <Michael.Hennerich@...log.com>,
        devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] iio: addac: ad74413r: add support for reset-gpio

On Mon, 14 Nov 2022 09:37:59 +0100
Rasmus Villemoes <linux@...musvillemoes.dk> wrote:

> On 12/11/2022 18.07, Jonathan Cameron wrote:
> > On Fri, 11 Nov 2022 15:39:21 +0100
> > Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> >   
> >> We have a board where the reset pin of the ad74412 is connected to a
> >> gpio, but also pulled low by default. Hence to get the chip out of
> >> reset, the driver needs to know about that gpio and set it high before
> >> attempting to communicate with it.  
> > 
> > I'm a little confused on polarity here.  The pin is a !reset so
> > we need to drive it low briefly to trigger a reset.
> > I'm guessing for your board the pin is set to active low? (an example
> > in the dt would have made that clearer) Hence the pulse
> > in here to 1 is actually briefly driving it low before restoring to high?  
> 
> Yes. I actually thought that was pretty standard. I do indeed have
> something like
> 
>   reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
> 
> in my .dts, so setting the gpio value to 1 (logically asserting its
> function) will end up driving the signal low, and setting it to 0
> (de-asserting reset) will set the signal high. I will add that line to
> the example in the binding.
> 
> > For a pin documented as !reset that seems backwards   
> 
> Well, it depends on where the knowledge of the pin being active low
> belongs. In this case, the driver itself handles the gpio so it could be
> done both ways.
> 
> But if, for example, the iio framework would handle an optional
> reset-gpio for each device, it couldn't possibly know whether to set it
> to 1 or 0 for a given device, it could only set it logic 1 to assert
> reset and then rely on DT gpio descriptor to include the active low/high
> info.
> 
> Also, see the "The active low and open drain semantics" section in
> Documentation/driver-api/gpio/consumer.rst.

Throw in an example in the dt-binding and I'm fine with this as it
stands.

Jonathan

> 
> Rasmus
>