dma_sync_sgtable_for_cpu(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… dma_sync_sgtable_for_cpu(9) β€” like, the whole glow-up

okay so bestie, welcome to the Kernel API Manual ✨ this one is a single function that does one job and does it iconically β€” it hands a buffer back to the CPU so your code can actually touch it without the DMA engine side-eyeing you. no cap.


🌸 NAME 🌸

dma_sync_sgtable_for_cpu β€” Synchronize the given buffer for CPU access 🫢


✨ SYNOPSIS ✨

void dma_sync_sgtable_for_cpu (struct device *dev , struct sg_table *sgt
, enum dma_data_direction dir );

literally that's the whole vibe. three args, void return, no drama.


πŸŽ€ ARGUMENTS πŸŽ€

  • dev β€” the device you're doing the DMA operation for. like, the main character of this whole thing πŸ‘‘
  • sgt β€” the sg_table object that describes the buffer. it's the map, the receipt, the whole description ok πŸ’…
  • dir β€” the DMA direction. which way the data's flowing, iykyk 🌈

πŸ¦‹ DESCRIPTION πŸ¦‹

so what does it actually do? it performs the needed cache synchronization and moves the ownership of the buffer back to the CPU domain πŸ”₯ which means: it is safe to perform any access to it by the CPU. yes bestie, go ahead, read it, write it, it's yours now πŸ’–

but listen β€” this is a handoff, not a forever thing. before doing any further DMA operations, one has to transfer the ownership of the buffer back to the DMA domain by calling the dma_sync_sgtable_for_device. don't ghost the DMA engine, it will Not be cute 😭

think of it like passing the aux cord back and forth 🎧 CPU has it now, but the second DMA wants a turn you must formally hand it over. no vibes-based ownership. periodt.


⭐ SEE ALSO ⭐

all of these are lowkey the friend group of this function. go say hi 🌸


and that's the page, bestie!! 🧚 this lil' beauty lives in ./include/linux and it's dated October 2026, and yeah the page itself is dma_sync_sgtable_for_cpu(9) β€” slay, ate, no crumbs πŸ’œβœ¨πŸŽ€

πŸ“¦ where this page comes from