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

Date:   Tue, 1 Dec 2020 17:41:54 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Sven Van Asbroeck <thesven73@...il.com>,
        kernel list <linux-kernel@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [BUG] SPI broken for SPI based panel drivers


> Am 01.12.2020 um 17:20 schrieb Mark Brown <broonie@...nel.org>:
> 
> On Tue, Dec 01, 2020 at 03:20:12PM +0100, Linus Walleij wrote:
> 
>> The reason why I shoot in the dark to convert all SPI
>> drivers to use GPIO descriptors instead of the global
>> GPIO numberspace is detailed in drivers/gpio/TODO
>> so I will not repeat it here.
> 
>> I don't know if much can be done about it other than
>> having better programmers than me at the task. Or
>> less tired when they write the patch. etc.
> 
> I think the problem here is more to do with where we started than where
> we're going or how we got there - things have been glued together or
> happened to work in ways that mean I'm not sure we reasonably understand
> the situation we started from or all the requirements it has.  As you
> say I'm not sure anything beyond throwing the API away and starting
> afresh would really help here, but that's not really how we tend to do
> things for a bunch of very good reasons.

I think the key problem is GPIO_ACTIVE_HIGH 0 and GPIO_ACTIVE_LOW 1
in device tree blobs. But that is so fundamental that we have to live with it.
So I guess that even a new API from scratch wouldn't improve that.