dma_port_flash_write(9)

📦 version 7.3.1, in nixpkgs unstable

💅 dma_port_flash_write(9) — the Kernel API Manual glow-up

okay so bestie, welcome to the dma_port_flash_write(9) page, straight out of the Kernel API Manual ✨ this one is short, sweet, and honestly kind of iconic — it's the "write stuff into the flash area that nobody's using right now" function. let's get into it 🎀

🌸 NAME 🌸

dma_port_flash_write — literally just write to the non-active flash region, no cap 💖

✨ SYNOPSIS ✨

int dma_port_flash_write (struct tb_dma_port *dma , unsigned int address
, const void *buf , size_t size );

yes queen, it returns an int. we love a return type with opinions 🫶

🦋 ARGUMENTS 🦋

  • dma — the DMA control port. your main character struct, struct tb_dma_port * and all 💅
  • address — the address relative to the start of the non-active region. not absolute, bestie, keep that in mind 🙈
  • buf — the data you're writing. the payload. the moment. const void * because we're not about to go mutating your stuff 🌸
  • size — size of the buffer. how much of buf is actually doing something 🔥

💜 DESCRIPTION 💜

so here's the vibe check: this function writes a block of data to the non-active flash region of the switch. that's the whole thing, fr fr 🍓

and then there's the little plot twist ✨ — if the address is given as DMA_PORT_CSS_ADDRESS, the block is written using the CSS command instead. it's giving "same function, different pathway." iykyk 💀

⭐ RETURN ⭐

  • 0 on success — slay, we ate 👑
  • negative errno otherwise — not slay, but at least it's informative 😭

🌈 SEE ALSO 🌈

go read these next, bestie, they're all in the kernel file ./drivers/thunderbolt/dma_port.c:

aaaand that's the page 💖 cute little sign-off for you: this lore lives in ./drivers/thunderbolt, dated October 2026 — so go forth, write to that non-active flash region, and remember: the active region is not your business today 🧚‍♀️✨🫶

📦 where this page comes from