snd_hdac_sync_power_state(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ snd_hdac_sync_power_state(9) ✨

okay bestie, welcome to the Kernel API Manual πŸ’… this one's a whole function, snd_hdac_sync_power_state, and honestly? its whole personality is waiting. like, it literally sits there until the actual power state matches the target state. no cap. 🫢


🌸 NAME 🌸

snd_hdac_sync_power_state β€” wait until actual power state matches with the target state

like it's not gonna return until the vibes (power states) line up. it's giving patient main character energy ✨


πŸŽ€ SYNOPSIS πŸŽ€

unsigned int snd_hdac_sync_power_state (struct hdac_device *codec ,
hda_nid_t nid , unsigned int power_state );

that's the whole signature, copy it exactly, don't be weird about it πŸ¦‹


πŸ’– ARGUMENTS πŸ’–

  • codec β€” the HDAC device. the whole audio codec bestie we're working with πŸ‘‘
  • nid β€” NID to send the command. this is the node id we're poking at 🎯
  • power_state β€” target power state to wait for. this is the destination, we're manifesting it ✨

πŸ”₯ DESCRIPTION πŸ”₯

Return power state or PS_ERROR if codec rejects GET verb. 😭

that's it, that's the whole thing. it returns the power state you asked about β€” but if the codec straight up rejects the GET verb, you get PS_ERROR back instead. rude of the codec honestly, but that's the deal πŸ’€


🌈 SEE ALSO 🌈

Kernel file ./sound/hda/core/device.c β€” the whole squad lives here, go read it, iykyk 🧚


fr fr, if you're deep in HDAC power-state land, snd_hdac_check_power_state(9) and snd_hdac_power_up(9) / snd_hdac_power_down(9) are your besties too β€” the whole list above is basically the group chat πŸ’œ

and that's the page!! πŸŽ€ sign-off time: this little cutie lives in ./sound/hda/core, it's stamped October 2026, and yes it's part of the snd_hdac_sync_power_state(9) manual. slay, go sync some power states, periodt πŸ’…πŸ”₯

πŸ“¦ where this page comes from