linux-kernel - Re: [BUG/PATCH 0/4] gpiolib: fix issues with legacy spi-cs-high handling

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] [day] [month] [year] [list]

Message-ID: <CACRpkdaM4t6c5gkLxv6CS559o_X=r14oP4=VoEhzyH4Du9socg@mail.gmail.com>
Date:   Tue, 2 Apr 2019 10:19:19 +0700
From:   Linus Walleij <linus.walleij@...aro.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [BUG/PATCH 0/4] gpiolib: fix issues with legacy spi-cs-high handling

On Mon, Apr 1, 2019 at 11:59 PM H. Nikolaus Schaller <hns@...delico.com> wrote:

> I learned just some minutes ago that a new patch for gpiolib
> came through 5.1-rc3 which does fix this in almost the same way
> as I proposed.

I am sorry for not being very attentive, I have been travelling.
I collected the most urgent fixes and this was fixed as part of
that quick patchup.

> Except that it seems to check for "cs-gpios" and then disable the
> legacy handling.

Yups.

> So we do not need to add a config option for this legacy
> handling (although I'd prefer to have it anyways to remove
> some dead code).
>
> Summary: this series can now be ignored.

OK please verify that we are doing things right now, the big
worry I have is some interrim DTBs that use the GPIO flag
GPIO_ACTIVE_HIGH, which is zero and therefore often the
default, and expect it to actually work, while the SPI bindings
by definition will ignore that and make the line active low.

I'm not very happy about this but it is a result of how we quickly
implemented some bindings in the past while the GPIO flags
were not yet standardized.

Yours,
Linus Walleij