Examination of the DSDT in a Framework laptop generally hints at
firmware designers sometimes providing ACPI methods for convenience
(e.g., same firmware for multiple models) but not using them (or not
expecting them to be used) depending on tweaks or the actual hardware
platform.
On an Intel Framework laptop, we specifically observe the presence of
a Microsoft DSM that just reports availability of the SLEEP_ENTRY and
SLEEP_EXIT (7 and 8) functions although the Microsoft specification
requires other functions, whose purpose is similar to corresponding
Intel DSM's ones (such as DISPLAY_OFF). However, we currently always
call the latter even on the Microsoft DSM. On that laptop, fortunately,
the way the code is structured in the _DSM method leads to nothing being
executed on this call.
Given the similarity of intent between most functions from the Microsoft
DSM on one side and those of ADM and Intel on the other, it is
imaginable that other firmware developers could use a strategy where
functions are in fact aliased, in which case insisting on calling the
Microsoft's DSM function even if not enumerated would cause the action
to be performed twice (because we also call the corresponding function
on the Intel/AMD DSM), which may or may not cause other problems and in
any case seems a waste.
So, by default, do not try to run any function that is not enumerated,
as that looks like the safest approach. Add a debug sysctl(8) knob to
revert to the previous behavior, just in case
('debug.acpi.spmc.force_call_expected_functions').
acpi_spmc_run() now checks if a DSM/function combination has been
enumerated, and skips the actual call if it does not. This allows to
remove all checks from the acpi_spmc_*_notif() functions, making the
code much more compact.
acpi_spmc_get_constraints() now checks whether
DSM_GET_DEVICE_CONSTRAINTS is supported in order to determine which DSM
to use and whether to call the function at all.
Sponsored by: The FreeBSD Foundation