acpi: New R/O 'hw.acpi.s4bios_supported' sysctl, gate S4BIOS with it

[olce]

Summary

This new sysctl knob indicates whether the ACPI implementation supports
S4BIOS (FACS present with bit S4BIOS_F set, as per the standard).

If S4BIOS is not supported, do not allow 'hw.acpi.s4bios' to be set to
true.

This is also in preparation of probably switching the default for
'hw.acpi.s4bios' to false once OSPM-initiated S4 support is ready, in
which case administrators need some way to determine whether
firmware-initiated S4 support is possible. For now, we keep the default
of setting 'hw.acpi.s4bios' to true (1) when S4BIOS is supported.

[obiwac]

Should we even allow hw.acpi.s4bios to be set if not supported? feels like it could be confusing to users not super familiar with power management that hw.acpi.s4bios is set but the system is not entering S4BIOS.

sys/dev/acpica/acpivar.h

533

nitpick, but i think acpi_should_do_s4bios or something is a clearer name that acpi_S4_should_firmware_initiate

[olce]

Prevent users to set hw.acpi.s4bios to true if S4BIOS is not supported.

Generally, it wouldn't be prudent for backwards-compatibility to forbid a value that was accepted before. But I think it's fine to do in this case, because we always set hw.acpi.s4bios to 1 when S4BIOS is supported, and anyway we did not support OSPM-initiated S4. So, basically, no one should be trying to set hw.acpi.s4bios to true if it wasn't true by default (which means S4BIOS is supported), and if they did, that would probably just cause a crash or some malfunction but not a suspend, so keeping such a tuning was pointless, and continuing to allow it would be silly. We might want to have an extra debug knob if we ever want to force trying S4BIOS even if not reported.

[olce]

Update commit message