Documentation/spi/spidev.rst
Source file repositories/reference/linux-study-clean/Documentation/spi/spidev.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/spi/spidev.rst- Extension
.rst- Size
- 8229 bytes
- Lines
- 192
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
fcntl.hunistd.hsys/ioctl.hlinux/types.hlinux/spi/spidev.h
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
=================
SPI userspace API
=================
SPI devices have a limited userspace API, supporting basic half-duplex
read() and write() access to SPI slave devices. Using ioctl() requests,
full duplex transfers and device I/O configuration are also available.
::
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>
Some reasons you might want to use this programming interface include:
* Prototyping in an environment that's not crash-prone; stray pointers
in userspace won't normally bring down any Linux system.
* Developing simple protocols used to talk to microcontrollers acting
as SPI slaves, which you may need to change quite often.
Of course there are drivers that can never be written in userspace, because
they need to access kernel interfaces (such as IRQ handlers or other layers
of the driver stack) that are not accessible to userspace.
DEVICE CREATION, DRIVER BINDING
===============================
The spidev driver contains lists of SPI devices that are supported for
the different hardware topology representations.
The following are the SPI device tables supported by the spidev driver:
- struct spi_device_id spidev_spi_ids[]: list of devices that can be
bound when these are defined using a struct spi_board_info with a
.modalias field matching one of the entries in the table.
- struct of_device_id spidev_dt_ids[]: list of devices that can be
bound when these are defined using a Device Tree node that has a
compatible string matching one of the entries in the table.
- struct acpi_device_id spidev_acpi_ids[]: list of devices that can
be bound when these are defined using a ACPI device object with a
_HID matching one of the entries in the table.
You are encouraged to add an entry for your SPI device name to relevant
tables, if these don't already have an entry for the device. To do that,
post a patch for spidev to the linux-spi@vger.kernel.org mailing list.
It used to be supported to define an SPI device using the "spidev" name.
For example, as .modalias = "spidev" or compatible = "spidev". But this
is no longer supported by the Linux kernel and instead a real SPI device
name as listed in one of the tables must be used.
Not having a real SPI device name will lead to an error being printed and
the spidev driver failing to probe.
Sysfs also supports userspace driven binding/unbinding of drivers to
devices that do not bind automatically using one of the tables above.
To make the spidev driver bind to such a device, use the following::
echo spidev > /sys/bus/spi/devices/spiB.C/driver_override
echo spiB.C > /sys/bus/spi/drivers/spidev/bind
When the spidev driver is bound to a SPI device, the sysfs node for the
device will include a child device node with a "dev" attribute that will
Annotation
- Immediate include surface: `fcntl.h`, `unistd.h`, `sys/ioctl.h`, `linux/types.h`, `linux/spi/spidev.h`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.