acpi_spmc(4): Gracefully support only the Microsoft DSM

[olce]

Summary

In acpi_spmc_get_constraints(), stop assuming that if there is no AMD
DSM, then the Intel one is present. Although this is likely to be the
overwhelming majority of cases on amd64, there is no technical reason
nor constraint in our code that really needs assuming that. On (so far
hypothetical) machines with only the Microsoft DSM, this assumption
would cause a cryptic and irrelevant error message (and, prior to the
previous commit, a panic on INVARIANTS).

Warn the user if both the Intel and AMD DSMs are present, and use the
constraints reported by the Intel one (see the comment for why).

[olce]

• Tolerate the presence of both AMD and Intel DSMs by favoring Intel's (should never happen).
• Mention that min_d_state is a single field for a piece of information provided by both, so we cannot store constraints from both (that's not the only reason though, and I might update the text again on commit).

[obiwac]

sys/dev/acpica/acpi_spmc.c

612–614

maybe a comment to tell the user to check if hell has frozen over ;)

618

in this situation, maybe we wanna have get_constraints_succeeded compile on non-INVARIANTS, and then just return early from acpi_spmc_check_constraints() if this is false? in case we just have the microsoft dsm

[obiwac]

sys/dev/acpica/acpi_spmc.c

618

I know currently this will still work because sc->constraints_count == 0, but then since violation == false, it will print that the constraints are respected. We should probably just not print anything in that situation

[olce]

sys/dev/acpica/acpi_spmc.c

612–614

Ha ha

618

I see, but then it seems a bit more useful to just handle the sc->constraints_count == 0 instead, in case some firmware manufacturer does not report any constraints. Going to add an early bail out to the relevant commit.

[olce]

Impacts of changes in earlier revisions, no real change.