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: <2oxhmcrhbwlwqgyqy62p77eoag6nkavhjwmwfjfizcrhunrkjv@eaxjy6uoxszq>
Date: Tue, 25 Mar 2025 17:38:57 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Mark Brown <broonie@...nel.org>
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 03:55:02PM +0000, Mark Brown wrote:
> 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.

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?

I think the more common use-case is for things like these semi-standard
expansion headers you see on embedded devices that expose things like
GPIOs, I2C and SPI pins. In some cases users might end up installing
off-the-shelf expansion boards and they will be happy to add device tree
overlays to add whatever is available on that board. Again, for these I
suspect a kernel driver matching on that compatible string is more
appropriate.

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.

Thierry

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