linux-kernel - Re: [PATCH] spi: spidev: Add compatible for external SPI ports on Kontron boards

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:   Wed, 15 Jul 2020 09:26:29 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org
Subject: Re: [PATCH] spi: spidev: Add compatible for external SPI ports on
 Kontron boards

On 14.07.20 21:29, Mark Brown wrote:
> On Tue, Jul 14, 2020 at 10:54:15AM +0200, Frieder Schrempf wrote:
> 
>> It would still be quite nice to benefit from the flexibility of DT overlays
>> not only for the SPI use case. But before I come up with any custom
>> solution, for now I will rather have the device in the DT statically.
> 
>> I just wonder if I need to keep the DT node for the device in a separate
>> patch in our own tree, or if a node with a custom compatible string like for
>> example "kontron,user-spi" would be accepted upstream, without a matching
>> driver?
> 
> I'm having a hard time getting enthusiastic about it TBH - can you not
> just use spidev and live with the warning?

Ok, I can do that, but when I resend my patches and add "compatible = 
'spidev'" to my DT I expect someone to complain again as my DT does not 
describe the hardware.

Seeing that there are quite a few DTs that still do it like this, I 
probably will try it still and also keep a patch in our tree to remove 
the warning so customers won't be getting worried.

But for obvious reasons this can't be considered a good solution and it 
seems somewhat disturbing that the maintainer needs to propose it 
because of lack of proper solutions ;)