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: <ljxxml7z2k6xniamzzw4ssi7u75qqfpcvmidzy3ekr3imtoxau@eztnxovsjplg>
Date: Tue, 25 Mar 2025 14:05:01 +0100
From: Thierry Reding <thierry.reding@...il.com>
To: Mark Brown <broonie@...nel.org>, Jon Hunter <jonathanh@...dia.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 Tue, Mar 25, 2025 at 01:45:26PM +0100, Thierry Reding wrote:
> On Tue, Mar 25, 2025 at 12:10:19PM +0000, Mark Brown wrote:
> > On Tue, Mar 25, 2025 at 10:36:29AM +0000, Jon Hunter wrote:
> > > On 27/11/2024 17:31, Mark Brown wrote:
> > 
> > > > You can put 'spidev' in as the compatible and get the warning, we don't
> > > > require specific compatibles if the Linux device ID is good enough.  If
> > > > you genuinely just have bare wires you're probably able to cope with the
> > > > warning.  If something is actually connected you should use the
> > > > compatible for whatever that is, if spidev makes sense for it then
> > > > that'd be OK to add to spidev.
> > 
> > > We finally got back to this. Looks like just having 'spidev' as the
> > > compatible does not work. Apparently, it use to work and yes you would get
> > > the warning, but that no longer seems to be the case. I see a few others
> > > have been doing similar things and hacking their device-trees in different
> > > ways [0].
> > 
> > Huh, OK.  I don't recall any deliberate SPI change for that.
> 
> People in the discussion that Jon linked to indicated that it was this
> patch that caused the "regression":
> 
> commit 6840615f85f6046039ebc4989870ddb12892b7fc
> Author: Mark Brown <broonie@...nel.org>
> Date:   Thu Sep 23 18:00:23 2021 +0100
>     spi: spidev: Add SPI ID table
>     
>     Currently autoloading for SPI devices does not use the DT ID table, it uses
>     SPI modalises. Supporting OF modalises is going to be difficult if not
>     impractical, an attempt was made but has been reverted, so ensure that
>     module autoloading works for this driver by adding an id_table listing the
>     SPI IDs for everything.
>     
>     Fixes: 96c8395e2166 ("spi: Revert modalias changes")
>     Signed-off-by: Mark Brown <broonie@...nel.org>
>     Link: https://lore.kernel.org/r/20210923170023.1683-1-broonie@kernel.org
>     Signed-off-by: Mark Brown <broonie@...nel.org>
> 
> If you say that the regression wasn't deliberate, maybe we should look
> at fixing this so that people don't have to work around stuff?

Hm... there's also this:

commit f6f6a6320eeeb3e80e1393f727f898f8ca976bfd
Author: Javier Martinez Canillas <javierm@...hat.com>
Date:   Fri Nov 19 13:11:39 2021 +0100
    spi: docs: improve the SPI userspace API documentation

    This doc is fairly outdated and only uses legacy device instantiation
    terminology. Let us update it and also mention the OF and ACPI device
    tables, to make easier for users to figure out how should be defined.

    Also, mention that devices bind could be done in user-space now using
    the "driver_override" sysfs entry.

    Suggested-by: Ralph Siemsen <ralph.siemsen@...aro.org>
    Signed-off-by: Javier Martinez Canillas <javierm@...hat.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
    Link: https://lore.kernel.org/r/20211119121139.2412761-1-javierm@redhat.com
    Signed-off-by: Mark Brown <broonie@...nel.org>

That explicitly says that the linux,spidev or spidev compatible strings
are no longer supported, but also mentions the sysfs interface to bind
spidev to a given device.

Jon, I take it that the current sysfs is not enough for our use-case
because it only works if a device is predefined (i.e. the sysfs doesn't
allow specifying the chipselect)? Maybe we could enhance sysfs to allow
adding a generic spidev client, similar to how other busses (USB, PCI, I
think) allow using configfs to create these devices at runtime.

I2C has a different mechanism that could perhaps be used to achieve
something similar, except that it exposes each controller as a device
with a set of defined IOCTLs. That would be another option, but given
that there's already a spidev interface that doesn't seem like a good
fit for SPI.

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.

Thierry

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