SPI总线上有两类设备：
- 一类是主控端，通常作为SoC系统的一个子模块出现，比如很多嵌入MCU中常包含SPI模块。
- 一类是受控端，例如一些SPI接口的射频芯片、传感器等。
主控端是SPI总线的控制者，通过使用SPI 协议主动发起SPI总线上的会话。而受控端则被动接受SPI主控端的指令，并作出响应。
Linux 目前只支持SPI主控端，不支持SPI受控端。
参考：3.0.35 源码中include/linux/spi/spi.h 中相关说明
/* * INTERFACES between SPI master-side drivers and SPI infrastructure. * (There's no SPI slave support for Linux yet...) */ extern struct bus_type spi_bus_type;
Linux 中的SPI是依靠 SPI子系统实现的。这个子系统向下直接和SPI主控设备硬件交互，读取SPI总线上的数据。
向上则和FS子系统，MTD子系统，字符设备子系统等交互，给用户空间提供访问接口。
在内核 SPI 子系统中，包含两类设备驱动。一类称之为 controller driver， 用于驱动SPI主控设备，以和SPI总线交互，读写通信数据。
另一类称之为 protocol driver，用于解析controller driver 读取的数据，形成有意义的协议数据。
SPI 子系统中的两种设备，一种是由controller driver 驱动的，称之为spi_master，另一种是由 protocol 驱动的，称之为
spi_device。内核之所以把SPI子系统这么划分，是因为SPI主控器功能单一，只负责和SPI总线交互，读写数据。但数据
的具体含义，根据SPI总线上的设备不同而千差万别。
内核一方面把SPI通信系统分成上面两个部分，另一方面创建了一个SPI核心系统，用于连接这两部分。在有数据请求时，
protocol 解析请求生成通信帧并发送到SPI核心子系统中，SPI的核心子系统通过 protocol driver的信息，找到对应的
controller driver，并将这个通信帧发送给 controller driver， controller driver接收到这个帧后发送到 spi 总线上。
故，SPI通信的数据流大致是：
- 1、用户请求 -> protocol driver 分析请求，生成spi通信帧 -> 通信帧传至spi核心子系统 -> 通信帧传至对应的 controller driver -> 通信帧传至spi 总线上
- 2、spi设备返回数据 -> 数据传至spi总线上 -> 数据传至controller driver -> 数据传至 spi 核心子系统 -> 数据传至protocol driver并解析数据 -> 解析后的数据返回给用户
在linux 内核中，这样的通信帧通过一个叫 spi_message 的结构体来实现。