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: <499703ae-dba1-49a6-869b-a60b44c2a85f@sirena.org.uk>
Date: Tue, 25 Mar 2025 15:55:02 +0000
From: Mark Brown <broonie@...nel.org>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Jon Hunter <jonathanh@...dia.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 Tue, Mar 25, 2025 at 02:05:01PM +0100, Thierry Reding wrote:

> Mark, would another alternative be to add something like a sysfs export
> attribute? Something that you'd write a controller/chipselect pair to in
> order to create a spidev device? That has the benefit of removing this
> entirely from device tree where it doesn't belong, but still makes this
> option available to users that would otherwise have to resort to hacks.

Possibly?  I think I've lost track of what the use case is here, usually
for the spidev stuff DT overlays seem like they're the right thing but
perhaps this is different?  If we are doing this at runtime sysfs seems
like a reasonable way to trigger it, though you'd still need the DT to
describe the controller and the chipselects that are available.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)