STRUCT SPI_DRIVER(9)

📦 version 7.3.1, in nixpkgs unstable

✨ struct spi_driver(9) ✨

okay so real talk — this is a page straight out of the Kernel API Manual, and it's literally the blueprint for struct spi_driver, aka the host side "protocol" driver. bestie, it's giving main character energy for every SPI protocol driver out there 💅

🌸 NAME 🌸

struct spi_driver — the host side "protocol" driver, no cap 🫶

🦋 SYNOPSIS 🦋

here's the whole struct, exactly as it lives, don't touch a character of it:

struct spi_driver {
    const struct spi_device_id *id_table;
    int (*probe)(struct spi_device *spi);
    void (*remove)(struct spi_device *spi);
    void (*shutdown)(struct spi_device *spi);
    struct device_driver    driver;
 };

🎀 Members 🎀

okay so let's meet the cast, one field at a time 💖

  • id_table — the list of SPI devices this driver supports. it's literally the driver's "these are my people" list ✨
  • probe — this one binds the driver to the SPI device. here's the vibe: drivers can verify that the device is actually present, and they may need to configure characteristics (such as bits_per_word) which weren't needed for the initial configuration done during system setup. so yeah, probe is the "hi, are you really there? let me set you up properly" moment 🫶
  • remove — unbinds this driver from the SPI device. breakup era, but make it kernel 🥲
  • shutdown — the standard shutdown callback, used during system state transitions such as powerdown/halt and kexec. it's the "okay bestie, time to go night-night" callback 💀
  • driver — SPI device drivers should initialize the name and owner field of this structure. lowkey mandatory homework, don't skip it 📝

💜 Description 💜

so what is this thing? it represents the kind of device driver that uses SPI messages to interact with the hardware at the other end of a SPI link. the reason it's called a "protocol" driver is that it works through messages rather than talking directly to SPI hardware — and that direct-hardware job belongs to the underlying SPI controller driver, which is the one doing the work to pass those messages along. those protocols are defined in the specification for the device(s) supported by the driver. iykyk 🔥

as a rule, those device protocols represent the lowest level interface supported by a driver, and it will support upper level interfaces too. examples of such upper levels include frameworks like MTD, networking, MMC, RTC, filesystem character device nodes, and hardware monitoring. so yeah — the protocol layer is the foundations, and everything above it is the cute penthouse ✨🏙️

ngl this is one of those "small struct, huge responsibility" situations. respect it 👑

🌈 SEE ALSO 🌈

go read these next, bestie — they're all in the kernel file ./include/linux/spi/spi.h:

and that's the whole page, bestie! 🎀 this one lives in ./include/linux/spi, dated October 2026, and it goes out under the struct spi_driver(9) glow-up. mwah 💋✨

📦 where this page comes from