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: <25857b7f-5c10-46ec-b0b7-9ff89ca5ab1e@sirena.org.uk>
Date: Tue, 25 Mar 2025 17:05:41 +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 05:38:57PM +0100, Thierry Reding wrote:
> On Tue, Mar 25, 2025 at 03:55:02PM +0000, Mark Brown wrote:

> > 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.

> Heh... it's exactly the opposite for me. I feel like I don't understand
> the need for spidev with a specific compatible string. If you've got a
> compatible string (or in other words you have a device with a very
> specific SPI chip connected), then why would you want to access it from
> userspace? Isn't a proper kernel driver the better option in most cases?
> That usually allows for better abstraction via some other subsystem. I
> suppose there are cases where there may not be a subsystem, or for other
> reasons it's more convenient to have direct access from userspace to
> avoid the roundtrip. Or maybe users could be concerned about safety?

A lot of things would be happier with a driver, yes.  One of the use
cases that did make sense to me longer term was DSP/coprocessor type
things with flexible functions where distributing the firmware and
application that talks to it together makes sense.

> In other cases users may just want to connect something completely
> custom or just have a way to poke whatever they connect. There may not
> be a proper driver for it. Or it could perhaps even be used temporarily
> as a way to write a userspace driver conveniently before porting it to
> Linux.

> 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.

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