Skip to content

The open() method is not well suited to hot-plugged SPI device controllers (e.g. USB, Thunderbolt, PCIe and similar situations). #129

Open
@tim-seoss

Description

The Linux kernel usually doesn't guarantee that SPI bus numbers are predictable and persistent across reboots, and kernel upgrades etc.

As with other device special files (e.g. storage devices, network devices, serial ports), the Linux udev subsystem is the generic mechanism for creating persistent/predictable names for devices (including SPI bus numbers).

Whilst in many cases the SPI bus number is predicable (e.g. Raspberry Pi OS maintainers take steps to ensure the spi bus number remains stable), in general this is not the case (e.g. Beaglebone Black has swapped SPI bus numbers 0 and 1 more than once between major Linux kernel version upgrades).

Unfortunately the current open() method requires that the user of the extension knows the bus number because it hard-codes the use of /dev/spidevX.Y.

A solution would be to add a second alternative call e.g. open_path() which would allow the user to supply a persistent device name such as /dev/spi/by-path/ftdi232h_7821067-cs0. Such a filesystem path would typically be created automatically by the udev daemon when, and would take the form of a symbolic link to a (non-predictable) spidev character device file e.g. /dev/spidev/14.0.

Having studied the codebase, it would be possible to keep the existing open() call (for backward compatibility), whilst adding a more generic open_path() alternative.

I'll prepare a PR with a draft implementation, along with some sample udev rules, and documentation updates.

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions