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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <D1D5D5B7-72AB-42F7-A460-9B61932C869B@goldelico.com>
Date:   Wed, 9 Dec 2020 09:45:04 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Linus Walleij <linus.walleij@...aro.org>
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

Hi Linus,

> Am 09.12.2020 um 09:38 schrieb Linus Walleij <linus.walleij@...aro.org>:
> 
> 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 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

Ok, so in this line the L is ok.

> 
> 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

Ok, so my assumption about H is right and not the part in parenthesis with ???.

> 
>> +      3) Effectively this rule defines that the ACTIVE level of the
>> +         gpio has to be ignored
> 
> Nr 3 isn't tagged in the table.

Well, it was thought as a third but general note. Maybe should have been a *)
or omitted since the table stands for itself.

> 
> Yours,
> Linus Walleij

So let me prepare a patch with fixes for this.

BR and thanks,
Nikolaus