@@ -62,8 +62,8 @@ chips described as using "three wire" signaling: SCK, data, nCSx.
62
62
(That data line is sometimes called MOMI or SISO.)
63
63
64
64
Microcontrollers often support both master and slave sides of the SPI
65
- protocol. This document (and Linux) currently only supports the master
66
- side of SPI interactions.
65
+ protocol. This document (and Linux) supports both the master and slave
66
+ sides of SPI interactions.
67
67
68
68
69
69
Who uses it? On what kinds of systems?
@@ -154,9 +154,8 @@ control audio interfaces, present touchscreen sensors as input interfaces,
154
154
or monitor temperature and voltage levels during industrial processing.
155
155
And those might all be sharing the same controller driver.
156
156
157
- A "struct spi_device" encapsulates the master-side interface between
158
- those two types of driver. At this writing, Linux has no slave side
159
- programming interface.
157
+ A "struct spi_device" encapsulates the controller-side interface between
158
+ those two types of drivers.
160
159
161
160
There is a minimal core of SPI programming interfaces, focussing on
162
161
using the driver model to connect controller and protocol drivers using
@@ -177,10 +176,24 @@ shows up in sysfs in several locations:
177
176
/sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
178
177
179
178
/sys/class/spi_master/spiB ... symlink (or actual device node) to
180
- a logical node which could hold class related state for the
181
- controller managing bus "B". All spiB.* devices share one
179
+ a logical node which could hold class related state for the SPI
180
+ master controller managing bus "B". All spiB.* devices share one
182
181
physical SPI bus segment, with SCLK, MOSI, and MISO.
183
182
183
+ /sys/devices/.../CTLR/slave ... virtual file for (un)registering the
184
+ slave device for an SPI slave controller.
185
+ Writing the driver name of an SPI slave handler to this file
186
+ registers the slave device; writing "(null)" unregisters the slave
187
+ device.
188
+ Reading from this file shows the name of the slave device ("(null)"
189
+ if not registered).
190
+
191
+ /sys/class/spi_slave/spiB ... symlink (or actual device node) to
192
+ a logical node which could hold class related state for the SPI
193
+ slave controller on bus "B". When registered, a single spiB.*
194
+ device is present here, possible sharing the physical SPI bus
195
+ segment with other SPI slave devices.
196
+
184
197
Note that the actual location of the controller's class state depends
185
198
on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time,
186
199
the only class-specific state is the bus number ("B" in "spiB"), so
0 commit comments