acpi_pwm_get(9)

📦 version 7.3.1, in nixpkgs unstable

💅 acpi_pwm_get(9) — like, the Kernel API Manual page, bestie ✨

Okay so you're in the Kernel API Manual and the star of the show is acpi_pwm_get(9). Buckle up, this one's short but she's got lore 🎀

✨ NAME ✨

acpi_pwm_get — request a PWM via parsing "pwms" property in ACPI. That's the whole vibe, no cap 🦋

🌸 SYNOPSIS 🌸

struct pwm_device * acpi_pwm_get (const struct fwnode_handle *fwnode );

Literally just hand her a firmware node and she'll go find your PWM, periodt 💅

💖 ARGUMENTS 💖

  • fwnode — the firmware node you want her to pull the "pwms" property out of. That's it. That's the assignment 🫶

🧚 DESCRIPTION 🧚

So here's the tea: she returns the PWM device that got parsed from the fwnode plus the index specified in the "pwms" property ✨ — or a negative error-code if it all went sideways 😭. Anything she parses out of the device tree gets stored in the returned PWM device object, so it's all bundled up cute and ready for you 🎀

She's analogous to of_pwm_get — the way that family resemblance is giving main character energy — except con_id is not yet supported, so don't come for her about it 🙈

And your ACPI entries? They gotta look exactly like this, no improvising ⭐

Package () {"pwms", Package () { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}

Like, exactly that shape. The <PWM flags> part is optional but the rest is non-negotiable bestie 💀

🔥 RETURN 🔥

A pointer to the requested PWM device 💖 — or, if things went badly, an ERR_PTR-encoded error code. So yeah, vibe check your return value before you dereference it, fr fr 😭

👑 SEE ALSO 👑

Everything else in the PWM cinematic universe, all iconic, all worth a read 🌈 — and the kernel file ./drivers/pwm/core.c:

Okay that's the whole page, you ate that 💅✨ This cutie lives in ./drivers/pwm and she's dated October 2026 — go forth and request your PWMs responsibly, bestie 🫶🎀🦋

📦 where this page comes from