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: <20201201162035.GK5239@sirena.org.uk>
Date:   Tue, 1 Dec 2020 16:20:35 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        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

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)