linux-kernel - Re: [BUG] SPI broken for SPI based panel drivers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdYbGBT1gYZ06W7G-tjx9J4YG1bi1g2GOAUAH0tzH8YbNw@mail.gmail.com>
Date:   Wed, 9 Dec 2020 09:38:26 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Sven Van Asbroeck <thesven73@...il.com>,
        Lukas Wunner <lukas@...ner.de>,
        Mark Brown <broonie@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>,
        Andreas Kemnade <andreas@...nade.info>
Subject: Re: [BUG] SPI broken for SPI based panel drivers

On Sat, Dec 5, 2020 at 8:07 AM H. Nikolaus Schaller <hns@...delico.com> wrote:

> I find it interesting that so far nobody wants to take responsibility
> for a decision
(...)

What causes some consternation in this discussion is the appeal
to higher authority. The kernel community in general does not like
authority/responsibility by way of formal hierarchy.

Have you read this document? Especially point 1) Decisions:
https://www.kernel.org/doc/html/latest/process/management-style.html

(We can have a meta-discussion about this but it is not really your
point I believe.)

> > What I can do is to provide just a skeleton for the table that you or Linus
> > can fix/fill in and make a patch out of it. Is attached and the ??? is
> > something you should discuss and define.
>
> Please take the attached diff, comment it here and define the question marks
> according to your intention and then make a patch for the YAML bindings out
> of it. (I can't do because I don't know your intentions and what to write into
> the commit message).

I'll comment what I know, then you can send a proper patch to
Mark. But you really need more people than me to look at this.

> +      device node     | cs-gpio       | CS pin state active | Note
> +      ================+===============+=====================+=====
> +      spi-cs-high     | -             | H                   |
> +      -               | -             | L                   |
> +      spi-cs-high     | ACTIVE_HIGH   | H                   |
> +      -               | ACTIVE_HIGH   | L (or H ???)        | 1

When using GPIO descriptors it will be enforced to ACTIVE_LOW (L) with an
explicit warning in dmesg, see drivers/gpio/gpiolib-of.c

When using legacy GPIOs, will be enforced ACTIVE_LOW by the SPI
core.

> +      spi-cs-high     | ACTIVE_LOW    | H (or L ???)        | 2

When using GPIO descriptors it will be enforced to ACTIVE_HIGH (H) with an
explicit warning in dmesg, see drivers/gpio/gpiolib-of.c

> +      3) Effectively this rule defines that the ACTIVE level of the
> +         gpio has to be ignored

Nr 3 isn't tagged in the table.

Yours,
Linus Walleij