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] [day] [month] [year] [list]

Message-ID: <7e2e0a65-d67a-f839-0a25-cee7f883ee6c@kontron.de>
Date:   Thu, 16 Jul 2020 09:53:49 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Mark Brown <broonie@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH] spi: spidev: Add compatible for external SPI ports on
 Kontron boards

On 15.07.20 21:06, Geert Uytterhoeven wrote:
> On Mon, Jul 13, 2020 at 5:11 PM Mark Brown <broonie@...nel.org> wrote:
>> On Mon, Jul 13, 2020 at 03:19:52PM +0200, Frieder Schrempf wrote:
>>> I would have expected that there is some kind of existing userspace API to
>>> load an overlay manually, but it seems like there isn't!?
>>
>>> So what's the reasoning behind this? How can I solve this in a
>>> mainline-compliant way, meaning without either keeping downstream patches to
>>> bind spidev to my device or writing and maintaining code that does the
>>> overlay loading?
>>
>> Basically the reasoning is that nobody's done it rather than any grand
> 
> Nah, it's been done, but a bit unsafe, if you don't know what you're doing
> ("with great power come great responsibilities").
> 
> Please check out https://elinux.org/R-Car/DT-Overlays
> I do my best to keep topic/overlays branch up-to-date, and working.

Thanks! That looks like what I was searching for, but couldn't find it. 
So there's some work being done. That's good to know. We probably can't 
use it in this state, but that's still a lot better than nothing.

> 
>> design not to do it.  There's some issues for more complex connectors
>> present on multiple boards with mapping the same connector onto multiple
>> boards where a resource on the connector might be provided by different
>> things on the base board so it's not quite as trivial for them as it
>> should be.
> 
> There's a big list of issues at
> https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts
> In other words: more work to be done, to polish it, and make it safe(r).

I'm now getting a rough idea about the efforts and issues behind this, 
thanks.