Documentation/spi/spidev.rst

5 SPI devices have a limited userspace API, supporting basic half-duplex
19  * Prototyping in an environment that's not crash-prone; stray pointers
38     - struct spi_device_id spidev_spi_ids[]: list of devices that can be
42     - struct of_device_id spidev_dt_ids[]: list of devices that can be
46     - struct acpi_device_id spidev_acpi_ids[]: list of devices that can
52 post a patch for spidev to the linux-spi@vger.kernel.org mailing list.
66     echo spidev > /sys/bus/spi/devices/spiB.C/driver_override
67     echo spiB.C > /sys/bus/spi/drivers/spidev/bind
74 For a SPI device with chipselect C on bus B, you should see:
101 Since this is a standard Linux device driver -- even though it just happens
102 to expose a low level API to userspace -- it can be associated with any number
112 Standard read() and write() operations are obviously only half-duplex, and
113 the chipselect is deactivated between those operations.  Full-duplex access,
114 and composite operation without chipselect de-activation, is available using
137 	transfer SPI words.  Zero indicates MSB-first; other values indicate
138 	the less common LSB-first encoding.  In both cases the specified value
139 	is right-justified in each word, so that unused (TX) or undefined (RX)
155     - At this time there is no async I/O support; everything is purely
158     - There's currently no way to report the actual bit rate used to
161     - From userspace, you can't currently change the chip select polarity;
162       that could corrupt transfers to other devices sharing the SPI bus.
166     - There's a limit on the number of bytes each I/O request can transfer
170     - Because SPI has no low-level transfer acknowledgement, you usually
171       won't see any I/O errors when talking to a non-existent device.
183 The example shows one half-duplex RPC-style request and response message.