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: <c81d7e8b-bcce-46a8-8938-c1ead71a988d@nvidia.com>
Date: Mon, 31 Mar 2025 14:11:35 +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 31/03/2025 13:44, Mark Brown wrote:
> On Mon, Mar 31, 2025 at 01:34:21PM +0100, Jon Hunter wrote:
>> On 27/03/2025 15:33, Mark Brown wrote:
>>> On Wed, Mar 26, 2025 at 12:16:53PM +0000, Jon Hunter wrote:
> 
>>>> 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.
> 
> Why would you need to use a compatible string for anything?  I'd expect
> the overlay to add the entire new device, compatible and all.


We need a compatible string for the SPI device in device-tree. Sorry, 
but I am not sure how we can add a SPI device without one.

Can you confirm what you mean by 'overlay'? To me an overlay, is purely 
a device-tree overlay and even if we have a device-tree overlay, we are 
still missing the kernel driver part that matches the compatible string.

I could be completely missing your point here, but it is not obvious to 
me what you are suggesting?

Jon

-- 
nvpublic