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]

Message-Id: <460191B6-EDD3-46DE-A1ED-47F758F111E8@goldelico.com>
Date:   Tue, 1 Dec 2020 14:32:45 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        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>
Subject: Re: [BUG] SPI broken for SPI based panel drivers

Hi Sven,

> Am 01.12.2020 um 13:41 schrieb Sven Van Asbroeck <thesven73@...il.com>:
> 
> On Tue, Dec 1, 2020 at 4:04 AM H. Nikolaus Schaller <hns@...delico.com> wrote:
>> 
>> Then it should not have been applied to mainline but fully worked out and tested.

Well I only complain because you wrote that you knew that it may
break something else. So it is known to induces a regression.

But I did not know until I got a report from our own testing effort (we
run a vendor kernel and do tests all days over the week).

So I had to bisect what was going on. There could have been 100 reasons.
Took me several hours because I had to look at the display to see if
it is on or off after boot. There was no simple shell command to find out
and let the bisect run over night.

Maybe printing a "please check your spi setup" in spi_setup() with
a comment hinting at your patch would have saved me a lot of time.

> 
> That would be a reasonable expectation of a product. But Linux
> isn't a product, it's a hugely complex, shared system, which may
> form the basis of your product. The core maintainers aren't
> superhuman, nor do they have access to the 1000s of configurations
> and devices where Linux runs or will run. They do their very best,
> but if every change had to be 100% tested in every possible
> configuration, then few things could ever change, and Linux
> would slow down to a snail's pace.

> When your product is based on Linux and you pull a newer version
> off kernel.org, it's not unreasonable to expect the occasional
> breakage. In my case, when I moved from 5.7 to 5.9, some of the
> things that broke were my network chip, and most SPI drivers. That
> was a bad day, most pulls are trouble-free.

If it were occasional it would be good.... It is not the first time
that I have to do bisect tests to find what did go wrong upstream.
Even in LTS kernels and some of my fixes were backported later.

> I believe LTSes are more stable than 'stable releases' which are in
> turn more stable than RCs. The choice involves a trade-off between
> features, security and stability.
> 
> When you do run into a breakage, complaining on the mailing list
> is good, but posting a fix is better :)

I usually do - if I have the time to go the extra mile to fix something
what somebody else did break. But I need to have a lot of spare time
if I have no idea what made the regression for a device driver where I
know that it was not touched and have to study the details.

And for me it is much less effort (hours vs. seconds) to do a revert...
I could submit that as a quick fix :) But then you are not happy.

> This is my layman's understanding of the situation, I'm just a user
> and not a maintainer.

Me too...

Well, I am sort of maintainer of a vendor kernel that tries to
follow linus/master and fix things before we release an LTS.

That is why I need a solution and can not go back to some LTS or wait
for the next one...

Anyways, there is still time until v5.10.0 to fix it better than by
a revert.

> 
>>> 
>>>> 
>>>> What should we do?
> 
> Hopefully I have some time this week to look into your breakage,
> I may get overtaken by someone much more knowledgeable than
> me on spi-gpio.

Hm. Then we are already two of us who have not much knowledge about
spi-gpio...

Hope that you have an idea soon. I am happy to test any suggestions/patches/alternatives
better than a simple revert.

BR and thanks,
Nikolaus