Linux内核驱动中设备树混合GPIO与SPI的最佳实践咨询

直接把 GPIOD 条目加进 SPI 节点完全可行 #

别担心，这种做法不仅可行，还是内核社区处理这类SPI外设配套GPIO的常规操作。很多成熟驱动（比如带中断引脚的SPI传感器、带WP/HOLD引脚的SPI闪存）都是这么实现的——毕竟READY和BUSY是SPI从机的专属配套信号，和SPI传输强绑定，放在同一个节点里既能清晰体现硬件关联，驱动里取资源也更方便。

两种方案的对比与选择建议 #

方案1：SPI节点内集成GPIOD（优先推荐） #

• 核心优势：
  • 设备树可读性强：谁都能一眼看出这两个GPIO是给这个SPI从机配套的，不用翻找分散的节点。
  • 驱动代码更简洁：直接通过spi->dev设备对象，用devm_gpiod_get_optional()这类函数获取GPIO资源即可，不用额外折腾平台设备的注册、匹配逻辑，减少冗余代码。
  • 贴合内核惯例：查看内核源码中spi-flash.c或带中断的SPI传感器驱动，都是采用这种实现方式，后续维护也能跟上社区规范。
• 注意事项：
  • 设备树属性名要合规，比如用ready-gpios、busy-gpios，同时指定引脚的方向、电平特性（比如READY是输入且触发上升沿中断，可加上gpio-active-high标识）。
  • 驱动里尽量使用带devm_前缀的函数申请GPIO，内核会自动管理资源释放，避免手动清理代码的遗漏。

方案2：拆分到平台设备 #

• 适用场景：
  • 仅当这两个GPIO需要被其他驱动共享使用时（但你的场景中READY触发SPI传输、BUSY指示传输状态，大概率不存在共享需求）。
  • 或GPIO功能与SPI传输完全独立，属于单独控制逻辑时（显然你的情况不匹配）。
• 劣势：
  • 设备树和驱动复杂度上升，要维护两套设备-驱动匹配逻辑，容易引入bug。
  • 无法直观体现GPIO与SPI设备的从属关系，后续维护成本更高。

额外实用细节 #

• 中断处理轻量化：READY引脚的中断回调里不要直接执行SPI传输（SPI传输可能触发睡眠，中断上下文不允许），建议用工作队列（workqueue）或线程化中断（threaded irq），把实际传输逻辑调度到进程上下文执行。
• BUSY信号严格同步：BUSY的电平变化必须和SPI传输生命周期绑定——发起传输前置为有效电平，无论传输成功或出错，完成后都要恢复电平，避免状态不一致。
• 设备树overlay检查：确保SPI和GPIO的pinctrl配置正确，比如READY设为输入模式并根据硬件电路开启上拉/下拉，BUSY设为输出模式，不要搞反方向。

内容的提问来源于stack exchange，提问作者NielsProsch