udev rules for reliable/descriptive user space SPI device file?

[Tim Small <tim@buttersideup.com>]

Hello,

Sorry, not sure if debian-arm is a good place to discuss this, please
feel free to redirect me if not.

I'd be curious to know if this is a common problem, and if-so what other
solutions or alterations might be useful?

In the past I've had some hassle maintaining user-space software which
uses spidev to access various SPI peripherals (frequently on
daughter-boards etc.).

The most common pattern I've seen when using spidev seems to be to
hard-code a device file like /dev/spidev0.0 and then grumble loudly when
the SPI bus numbers change after a kernel upgrade (there are also
hot-pluggable SPI master devices like the USB drivers/spi/spi-dln2.c )


To fix this locally, I wrote these UDEV rules:

SUBSYSTEM=="spidev", IMPORT{parent}="OF_COMPATIBLE_0",
IMPORT{parent}="OF_NAME", IMPORT{builtin}="path_id"
SUBSYSTEM=="spidev", ENV{OF_COMPATIBLE_0}=="?*",
SYMLINK+="spi/by-compat/$env{OF_COMPATIBLE_0}"
SUBSYSTEM=="spidev", ENV{OF_NAME}=="?*",
SYMLINK+="spi/by-name/$env{OF_NAME}"
SUBSYSTEM=="spidev", ENV{ID_PATH}=="?*",
SYMLINK+="spi/by-path/$env{ID_PATH}"

... so I get for example:

root@cubev1test:~# ls -l /dev/spi/*
/dev/spi/by-compat:
total 0
lrwxrwxrwx 1 root root 15 Aug  1 15:32 scs_cube_mb_v1_j12 -> ../../spidev1.0
lrwxrwxrwx 1 root root 15 Aug  1 15:32 scs_cube_mb_v1_j6 -> ../../spidev0.0

/dev/spi/by-name:
total 0
lrwxrwxrwx 1 root root 15 Aug  1 15:32 con_j12 -> ../../spidev1.0
lrwxrwxrwx 1 root root 15 Aug  1 15:32 con_j6 -> ../../spidev0.0

/dev/spi/by-path:
total 0
lrwxrwxrwx 1 root root 15 Aug  1 15:32 platform-f8000000.spi ->
../../spidev0.0
lrwxrwxrwx 1 root root 15 Aug  1 15:32 platform-fc018400.spi ->
../../spidev1.0


I realise there are some problems with this as it stands (e.g. both the
by-name and by-compat entries aren't guaranteed unique), but with more
work, would something like this rule set be reasonable to add to e.g.
the udev package for inclusion in Debian?

Any feedback welcome.

Cheers,

Tim.


p.s. In case it's useful regarding the "by-compat" entries...

I'd previously used the common bodge of a dt overlay specifying
'compatible = "spidev";' to get the spidev driver to bind to particular
SPI slaves.

spidev now grumbles about this, and a mechanism was added to Linux 4.20
to dynamically bind spidev, so I added added the following rule:

# Bind spidev to all external SPI connectors
# Requires spi driver_override sysfs entry (Linux version 4.20+ and later).
#
# Based on https://patchwork.kernel.org/comment/22517905/ ; courtesy of
Jan Kundrát
#
# cannot use ATTR{driver_override}+="spidev" because it apparently only
runs after the PROGRAM
ACTION=="add|change", SUBSYSTEM=="spi",
ENV{MODALIAS}=="spi:cube_mb_v1_j[0-9]*", PROGRAM+="/bin/sh -c 'echo
spidev > %S%p/driver_override && echo %k >
%S%p/subsystem/drivers/spidev/bind'"


Associated dt entry:

spi0: spi@f8000000 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_spi0_default>;
        status = "okay";

        /* SPI bus (chip select 0) brought out to connector J6 */
        con_j6@0 {
                compatible = "scs,cube_mb_v1_j6";
                reg = <0>;
                spi-max-frequency = <50000000>;
        };
};