Re: [PATCH 1/2] spi: add new_device/delete_device sysfs interface

Mark Brown
2026-04-22T14:41:21Z

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]

On Mon, Apr 20, 2026 at 03:14:16AM +0000, Vishwaroop A wrote:
> Development boards such as the Jetson AGX Orin expose SPI buses
> on expansion headers (e.g. the 40-pin header) so that users can
> connect and interact with SPI peripherals from userspace. The
> standard way to get /dev/spidevB.C character device nodes for
> this purpose is to register spi_device instances backed by the
> spidev driver.

Copying in Francesco who's been working on similar things from the DT
overlay side.

> The new_device file accepts:
>
> <modalias> <chip_select> [<max_speed_hz> [<mode>]]
>
> where chip_select is required, while max_speed_hz and mode are
> optional and default to 0 if omitted. max_speed_hz == 0 is
> clamped to the controller's maximum by spi_setup(); mode == 0
> selects SPI mode 0 (CPOL=0, CPHA=0).

> +static ssize_t
> +new_device_store(struct device *dev, struct device_attribute *attr,
> + const char *buf, size_t count)

> + status = spi_add_device(spi);
> + if (status) {
> + spi_dev_put(spi);
> + return status;
> + }
> +
> + mutex_lock(&ctlr->userspace_clients_lock);
> + list_add_tail(&spi->userspace_node, &ctlr->userspace_clients);
> + mutex_unlock(&ctlr->userspace_clients_lock);
> + dev_info(dev, "%s: Instantiated device %s at CS%u\n", "new_device",
> + modalias, chip_select);

I think there's some entertaining locking issues here if someone decides
to try to unregister a controller while we're adding a device. The
controller is going to want the add_lock while it cleans up, and we have
a window where the device is known to the core via spi_add_device() so
could be deleted but might still end up on the userspace_clients list.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]