spi_write_then_read(9)

📦 version 7.3.1, in nixpkgs unstable

💫 spi_write_then_read (kernel API manual, section 9) 💫

okay bestie, so this whole page is from the Kernel API Manual, section 9, and it's literally about one function that writes a thing then reads a thing. iconic behavior honestly.

✨ NAME ✨

spi_write_then_read — SPI synchronous write followed by read 🦋

🌸 SYNOPSIS 🌸

int spi_write_then_read (struct spi_device *spi , const void *txbuf ,
unsigned n_tx , void *rxbuf , unsigned n_rx );

🎀 ARGUMENTS 🎀

  • spi — the device you're exchanging data with, periodt.
  • txbuf — the data that's getting written out. heads up: it does not need to be DMA-safe. ngl that's a whole relief.
  • n_tx — the size of txbuf, counted in bytes.
  • rxbuf — the buffer where the data you read lands. also not required to be DMA-safe 💅
  • n_rx — the size of rxbuf, in bytes.

👑 CONTEXT 👑

can sleep 😴 (yes, literally. this one's allowed to nap.)

💜 DESCRIPTION 💜

so what this does is a half duplex MicroWire style transaction with the device — it sends txbuf and then reads rxbuf. that's the whole arc, no cap.

The return value is zero for success, else a negative errno status code. and the vibe check on where you can call it: this call may only be used from a context that may sleep. so don't be out here calling it from somewhere spicy that can't sleep, fr fr.

Parameters to this routine are always copied using a small buffer. that's the tea. so if you're doing performance-sensitive or bulk transfer code, don't use this one — use spi_{async,sync}() calls with DMA-safe buffers instead. it's giving "right tool for the right job" ✨

⭐ RETURN ⭐

zero on success, else a negative error code. simple as that 💖

🌈 SEE ALSO 🌈

Kernel file ./drivers/spi/spi.c plus this whole glorious friend group:

anyway that's the page 🫶 it lives over in ./drivers/spi, dated October 2026, and it's filed under spi_write_then_read(9) — mwah, go read some SPI, ily 💅💖

📦 where this page comes from