acpi_dma_re...chan_by_name(9)

📦 version 7.3.1, in nixpkgs unstable

✨ acpi_dma_re...chan_by_name(9) ✨

okay so bestie, welcome to the Kernel API Manual 💅 this is acpi_dma_re...chan_by_name(9) and yes the title got truncated by the terminal, she's dramatic like that 🎀 we're literally about to learn how to grab a DMA slave channel by name and honestly? iconic.

🌸 NAME 🌸

acpi_dma_request_slave_chan_by_name — Get the DMA slave channel 🦋

⭐ SYNOPSIS ⭐

struct dma_chan * acpi_dma_request_slave_chan_by_name (struct device
*dev , const char *name );

like, that's the whole vibe. she returns a struct dma_chan *, no cap 💖

🎀 ARGUMENTS 🎀

  • dev — the struct device you're getting the DMA request from 🫶 it's giving "who is this for"
  • name — represents the corresponding FixedDMA descriptor for dev ✨ i.e. the little label that tells us which descriptor we're eyeing 👑

💜 DESCRIPTION 💜

so here's the tea ☕ — in order to support both Device Tree and ACPI in a single driver, we translate the names "tx" and "rx" right here, based on the most common case where the first FixedDMA descriptor is TX and the second is RX 🔥 literally the classic setup, iykyk.

and if the device has a "dma-names" property? 👀 then the FixedDMA descriptor indices are retrieved based on those — slay, proper lookup, main character energy ✨

otherwise the function falls back using hardcoded indices 🙈 (yes, the fallback is real, she's got a backup plan bestie 💅)

🌈 RETURN 🌈

Pointer to the appropriate dma channel on success 💖 or an error pointer 😭 (so like, always vibe check your return value, fr fr)

⚠️ heads up: it can come back as an error pointer — not NULL, an error pointer — so treat it accordingly before you go dereferencing anything 🙈

🧚 SEE ALSO 🧚

Kernel file ./drivers/dma/acpi-dma.c — and her whole friend group 👑:

and that's the page babes 🫶 brought to you by the fine folks over at ./drivers/dma, dated October 2026 ⭐ go forth and request your channels responsibly, ily, bye 💜🎀💅

📦 where this page comes from