of_dma_configure_id(9)

📦 version 7.3.1, in nixpkgs unstable

💫 of_dma_configure_id 💫

okay so this is a page straight out of the Kernel API Manual, and honestly? it's a little baddie. bestie, we're about to set up DMA configuration and it's gonna slay.

✨ NAME ✨

of_dma_configure_id — Setup DMA configuration 🎀

like, it configures DMA. that's the whole vibe. no cap.

🌸 SYNOPSIS 🌸

int of_dma_configure_id (struct device *dev , struct device_node *np ,
                         bool force_dma , const u32 *id );

look at her. four args, one int return, main character energy fr fr 💅

🦋 ARGUMENTS 🦋

  • dev — the device we're applying DMA configuration to 🫶 she's the one getting glowed up.
  • np — pointer to the OF node that's holding the DMA configuration. like, this is where the info lives, iykyk.
  • force_dma — a bool that decides whether the device is to be set up by of_dma_configure even if DMA capability is not explicitly described by firmware. so yeah, it's the "do it anyway" switch 😭 iconic.
  • id — optional const pointer value input id. yes bestie, optional, and yes it's a const u32 *, we love a little pointer ✨

💜 DESCRIPTION 💜

so what does she actually do? she tries to get the device's DMA configuration from DT and update it accordingly. that's it. that's the plot 🎬

and if platform code needs to use its own special DMA configuration (not me being extra 🙈), it can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events to fix up DMA configuration. like, that's the escape hatch, go off king 👑

🌈 SEE ALSO 🌈

the whole friend group honestly, they all ate 🔥

okay tiny reminder bestie: force_dma really does bypass the "firmware didn't describe DMA" situation, so don't be shocked when a device gets configured that you didn't think had DMA. that's the whole point of the flag 💀

mmm bye bestie!! this page lives in ./drivers/of, dated October 2026, and if you need to find her again just look for of_dma_configure_id(9) in the Kernel API Manual 💖✨🎀🦋💅

📦 where this page comes from