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]

Date:   Tue, 1 Dec 2020 15:05:14 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Sven Van Asbroeck <thesven73@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        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 13:16 schrieb Mark Brown <broonie@...nel.org>:
> 
> On Tue, Dec 01, 2020 at 09:59:43AM +0100, H. Nikolaus Schaller wrote:
>>> Am 30.11.2020 um 21:13 schrieb Sven Van Asbroeck <thesven73@...il.com>:
> 
>>> We knew that there was a chance that our fix would break something else.
>>> But hopefully "it fixes more than it breaks"
> 
>> Then it should not have been applied to mainline but fully worked out
>> and tested.
> 
> If you want to see better testing of things in mainline please
> contribute to the various kernel testing efforts that are out there,

> there's a huge range of systems out there using the kernel and it's
> simply not realistic to expect that they'll all be covered, the testing
> effort for the kernel is very much a community effort.  If there are
> things that are particularly important to you the best way to ensure
> that they are tested is to provide that testing yourself.

Well, having a working display of a portable device that has mainline
Linux support for many years is particularly important...

BTW, I am already part of this testing efforts out there. Because I test
almost all -rc when they arrive. So I just did what you propose,

And if I can locate the commit of a regression I write bug reports
like this one.

The only thing I could have done differently is to always test based
on linux-next but that is a less structured testing environment and has
its own pitfalls. But that would have revealed the issue only earlier
but not with less effort or with a quicker fix.

I am not sure if ít is realistic to dream of some way of informing/contacting
the potentially affected driver authors/maintainers to run a quick test
before it is merged upstream.

To be clear: I do not expect that there are no bugs at all (for that I know
Linux and software far too long). But I do not expect regression of the
type hopefully "it fixes more than it breaks".

Well, for me it (apparently) breaks more than it fixes. So the easiest fix
for me would be to revert the patch. But I am sure that then you are not
happy with it...

So let's set out for a better solution.

BR and thanks,
Nikolaus