Why exactly do you use a device interface rather than a sysctl? Is it just to make the functionality available to non-root users (i.e., members of the operator group)?

Do you have plans to expand the interface?

I thought about making this a sysctl and am still open to that, but having this as a device node does give us room to expand the interface in the future. No specific plans, but we may e.g. want to be able to report state change events.

having this be accessible by the operator group without CTLFLAG_ANYBODY was another reason, yes

Looks ok with one nit fixed.

I think we should consider renaming these constants, perhaps doing something as radical as POWER_SSTATE_TRANSITION_* => POWER_*, or perhaps keeping STATE (instead of SSTATE), before they are made publicly available (after which, we will have to provide them (almost) indefinitely).

I kind of rather keep the word "transition", as this differentiates it from sleep types and they aren't really states in and of themselves (e.g. POWER_SSTATE_TRANSITION_SUSPEND could be either s2idle or s2mem). But probably we can rename this to just POWER_TRANSITION_* at least.

I am still open for other naming suggestions anyways because honestly I'm not the biggest biggest fan of these names; I can imagine they'd be kinda confusing.

Is this the granularity we want to expose? I'm OK with what is available right now, and we can later add more to that list in order to allow requesting *precise* states (i.e., not rely on the value of the power_*_stype variables to know which internal state we will finally go into). But just wanted to hear your thoughts.

I definitely think there's value in having a generic "suspend transition" which doesn't have to concern itself with if its entering s2idle or s2mem. This is not the kind of distinction a user program should concern itself with. We could definitely have a different ioctl further down the line which allows us to select a specific sleep type though (but I don't think there's as much value in this).