linux-kernel - Re: [PATCH v5 1/2] mfd: arizona: Update reset pin to use GPIOD

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: <20180326083404.ewogeas2rdgbfvhh@localhost.localdomain>
Date:   Mon, 26 Mar 2018 09:34:04 +0100
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Lee Jones <lee.jones@...aro.org>, Rob Herring <robh+dt@...nel.org>,
        "Mark Rutland" <mark.rutland@....com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>
Subject: Re: [PATCH v5 1/2] mfd: arizona: Update reset pin to use GPIOD

On Sat, Mar 24, 2018 at 03:32:05PM +0100, Linus Walleij wrote:
> On Mon, Mar 12, 2018 at 4:52 PM, Charles Keepax
> <ckeepax@...nsource.cirrus.com> wrote:
> 
> > Now GPIOD has support for both pdata systems and for non-standard DT
> > bindings the Arizona reset GPIO can be converted to use it. Worth
> > noting gpiod_set_raw_value_cansleep is used to match the behaviour
> > of the old GPIOs. This is because the part is fairly widely used and
> > it is unknown how many DTs are correctly setting active low through
> > device tree, so to avoid breaking any existing users it is best to
> > match the previous behaviour.
> >
> > Signed-off-by: Charles Keepax <ckeepax@...nsource.cirrus.com>
> > ---
> The use of gpiod_set_raw* should be done with caution, but this
> is one of the cases where we need to take out the big hammer to
> make sure things stay compatible.
> 
> I haven't read why it is like so but I guess because the right flags
> in the device tree can not be guaranteed?
> 

Exactly yes there are a lot of these parts out there and since
they never required the DT flags to be set correctly before I
very much doubt all those DTs are set correctly.

Thanks,
Charles