acpi: On /dev/power suspend, trigger userspace notifications

[olce]

Summary

On a suspend request via ioctl(), /dev/acpi (and compatible /dev/apm)
both call acpi_ReqSleepState() instead of directly calling
acpi_EnterSleepState(). The former does more checks, returns success if
the machine is already suspending, and notifies user space (via devd(8))
about the impending suspend. In other words, it seems to have been
designed for user consumption more than the latter function.

So, use acpi_ReqSleepState() in place of acpi_EnterSleepState() in
acpi_pm_func(), which is ultimately called by power_pm_suspend(), itself
called by power_ioctl(). Other callers of power_pm_suspend() (such as
the console drivers) are also user-facing facilities, so should also
benefit from this change.

Sponsored by: The FreeBSD Foundation

[mhorne]

LGTM, and it works! Thanks for chasing it down.

Tested by: mhorne

sys/dev/acpica/acpi.c

5079–5089

Just curious, does this have any functional purpose anymore?

[olce]

sys/dev/acpica/acpi.c

5079–5089

You mean, the SYSINIT() itself? It seems to be used to "grab" the unique power manager slot early, and then there's a later call to acpi_pm_register() in acpi_attach() just to pass the new softc pointer. But, today, I don't see any other users of power_pm_register() outside of ACPI.

That said, some infrastructure of this kind will be needed to allow suspending machines with suspend-to-idle on architectures where there is no ACPI. Which ones concretely, I don't really know, you probably know much more than me, e.g., RISC V? non-server arm64 machines? I'm not too sure about the status of ACPI on arm64 platforms.

[obiwac]

sys/dev/acpica/acpi.c

5079–5089

I was kinda wondering the same thing. I don't quite know why we don't just do this on attach. My opinion is that we should try removing this.