linux-kernel - Re: [PATCH 2/3] dt-bindings: spi: Add DT schema for Tegra SPIDEV controller

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: <69aaba89-10c6-408e-b328-c3e31a1aeaf7@nvidia.com>
Date: Mon, 31 Mar 2025 13:34:21 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Mark Brown <broonie@...nel.org>
Cc: Thierry Reding <thierry.reding@...il.com>, Vishwaroop A <va@...dia.com>,
 krzk+dt@...nel.org, robh@...nel.org, conor+dt@...nel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-tegra@...r.kernel.org, linux-spi@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: spi: Add DT schema for Tegra SPIDEV
 controller


On 27/03/2025 15:33, Mark Brown wrote:
> On Wed, Mar 26, 2025 at 12:16:53PM +0000, Jon Hunter wrote:
>> On 25/03/2025 17:05, Mark Brown wrote:
> 
>>>> The way I imagine it, exporting would involve writing a chip-select to a
>>>> specific SPI controller's "export" sysfs attribute to have a SPI device
>>>> created for that particular chip-select and bind it to spidev.
> 
>>> My general feeling with those is that if you're building for them you're
>>> probably either already modifiying your kernel or easily able to cope
>>> with doing so.
> 
>> That's definitely what we do today, modify the kernel directly to achieve
>> what we need. I am trying to avoid carrying too many out of tree patches for
>> stuff like this and have something in the kernel that works by default. This
>> is even more important for 3rd party Linux distros that will not accept
>> non-upstream code.
> 
> Overlays should work well for that case too!


If you mean device-tree overlays, I don't see how that will work today. 
Unless we are to use one of the existing compatible strings, but that 
feels wrong because we are not using any of those devices and like I 
mentioned, just using 'spidev' alone in device-tree does not work with 
the latest kernels.

Jon

-- 
nvpublic