pwm_init_state(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… pwm_init_state(9) β€” the kernel API manual, bestie edition πŸŽ€

okay so this is a page from the Kernel API Manual, and it's literally about getting a PWM state all dressed and ready for its big moment. no cap, it's short but it's iconic ✨


🌸 NAME 🌸

pwm_init_state β€” prepare a brand-new state so you can later apply it with pwm_apply_might_sleep() 🫢


✨ SYNOPSIS ✨

void pwm_init_state (const struct pwm_device *pwm , struct pwm_state
*state );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • pwm β€” the PWM device in question, your main character πŸ’…
  • state β€” the state you're gonna fill up with the freshly prepared PWM state, like a little tote bag you're packing πŸŽ€

πŸ’– DESCRIPTION πŸ’–

so this function prepares a state that you can totally tweak later and then apply to the PWM device with pwm_apply_might_sleep. it's the convenient-girlie function of the family: first it retrieves the current PWM state, then it replaces the period and polarity fields with the reference values defined in pwm->args. lowkey genius 🧚

once the function returns, you're free to adjust the ->enabled and ->duty_cycle fields however you need before you call pwm_apply_might_sleep. do your thing πŸ‘‘

and listen β€” ->duty_cycle starts out set to zero, and that's on purpose. it's there to dodge the situation where the current ->duty_cycle value exceeds the pwm_args->period one, which would trigger an error if you called pwm_apply_might_sleep without adjusting ->duty_cycle first. so yeah, zero is not a vibe, it's a safety net 😭

ngl bestie, that last bit is the important one β€” if you skip it and call pwm_apply_might_sleep straight away without touching ->duty_cycle, you can get an error. adjust first, slay after πŸ’€

🌈 SEE ALSO 🌈

Kernel file ./include/linux/pwm.h plus all these lil friends:


and that's the whole page, bestie 🫢 this lil gem lives under ./include/linux and the version dated October 2026 β€” go off, October, you ate πŸ’…βœ¨

πŸ“¦ where this page comes from