spi_mem_dirmap_read(9)

📦 version 7.3.1, in nixpkgs unstable

💅 spi_mem_dirmap_read — read data through a direct mapping ✨

okay so bestie, welcome to the spi_mem_dirmap_read(9) page from the Kernel API Manual 🫶 this is the little function that pulls data out of a memory device through a direct mapping, and honestly? it's giving "fast lane for your bytes" 🌈

✨ NAME ✨

spi_mem_dirmap_read — read data through a direct mapping 💖

🎀 SYNOPSIS 🎀

ssize_t spi_mem_dirmap_read (struct spi_mem_dirmap_desc *desc , u64 offs
, size_t len , void *buf );

that's the whole signature, no cap. four things go in, and a ssize_t comes out 👑

🌸 ARGUMENTS 🌸

  • desc — the direct mapping descriptor. this is your lil handle to the mapping, your backstage pass 🎟️
  • offs — offset to start reading from. ⚠️ and like, pay attention here bestie: this is not an absolute offset, it's the offset within the direct mapping — which already has its own offset. so don't go adding things up, iykyk 🙈
  • len — length in bytes, obviously 💅
  • buf — destination buffer. this buffer must be DMA-able, no exceptions, that's a hard requirement 🔥

🦋 DESCRIPTION 🦋

this function reads data from a memory device using a direct mapping that was previously instantiated with spi_mem_dirmap_create. so like, the mapping has to exist already — you can't just show up uninvited, that's not main character energy, that's just rude 😭

⭐ RETURN ⭐

it returns the amount of data read from the memory device, or a negative error code if things went sideways 💀

🚨 big heads up: the returned size might be smaller than len, and if that happens the caller is responsible for calling spi_mem_dirmap_read again. so yeah, you gotta loop, bestie — it's not a one-and-done situation 🙈

👑 SEE ALSO 👑

the kernel file ./drivers/spi/spi-mem.c plus the whole friend group 🌸

and that's the page, periodt 💜 this one lives under ./drivers/spi, dated October 2026, and it's part of the Kernel API Manual — go read the source, it ate 🍓✨

📦 where this page comes from