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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <63b87feb-32ee-423c-8d82-61445414c6f7@nvidia.com>
Date: Wed, 26 Mar 2025 12:16:53 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Mark Brown <broonie@...nel.org>, Thierry Reding <thierry.reding@...il.com>
Cc: 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 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.

Our devkits, very much like Raspberry PI, allow users to connect various 
hardware for development and so having an easy way to connect a SPI 
device is useful. For any production systems, users will definitely want 
a proper device and device-tree bindings. So I am just trying to explore 
what would be acceptable. If it is acceptable to have a sysfs interface 
for creating a SPI device at runtime, then we can look into that.

Cheers!
Jon

-- 
nvpublic