linux-kernel - Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel

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: <F8ACE730-B498-41E2-A486-923C760807F8@goldelico.com>
Date:   Tue, 2 Apr 2019 08:37:23 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Kumar Gala <galak@...eaurora.org>,
        Wolfgang Ocker <weo@...coware.de>,
        Jan Kotas <jank@...ence.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [BUG] gpiolib: spi chip select legacy support breaks modern chip select and whitens the GTA04 LCD panel


> Am 02.04.2019 um 07:31 schrieb Mark Brown <broonie@...nel.org>:
> 
> It's relatively common, especially with older devices, for people to be
> perfectly happy to update the kernel and do so frequently but unwilling
> to update the bootloader as the procedure for recovering a broken
> bootloader is difficult or perhaps not even possible.

Yes, that is the case Linus tries to solve, where it is not even possible
to modify the DTB. No idea how it could be solved if it would not be
possible to change our 6 years old DTB.

Fortunately we do not need to change it at all with the latest check for
cs-gpios.

> 
>> This also gives another idea: make it depend on "powerpc".
> 
> That won't fly, the code has always been architecture neutral.

Ok. Just an idea.

> 
>>> Dunno about this, it looks fragile, I would prefer to keep all working.
>>> But I will listen to reason.
> 
>> Reason why I propose a CONFIG option is:
> 
>> if someone is able to compile and deploy a v5.1 kernel for some device which
>> has (old) and problematic DTB in ROM he/she must have access to the .config.
>> So it is easy to modify it to enable legacy handling of spi-cs-high. And keep
>> it disabled for all others.
> 
> This assumes people aren't able to run a distro kernel...

Yes, indeed.

I have learned from Linus that the problem with legacy spi-cs-high are mostly embedded
powerpc systems deployed between 2008 and 2013 where the boot-loader can't be
changed. And where the dts is not maintained on kernel.org.

IMHO it is very unlikely that they are running distro kernels. Or is there an example
of such a system?

BR and thanks,
Nikolaus