diff options
author | Al Stone <ahs3@redhat.com> | 2019-08-27 18:21:20 -0600 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-10-05 12:27:49 +0200 |
commit | 318e486d4ed967187b91957d1683b8e75e2b1ea6 (patch) | |
tree | 8428551f72fc59c889b97ef3a2ebefe247a4b87d /drivers/acpi/custom_method.c | |
parent | 7ff7d1e7a749843920201489aaed20154eff5a15 (diff) |
ACPI / CPPC: do not require the _PSD method
[ Upstream commit 4c4cdc4c63853fee48c02e25c8605fb65a6c9924 ]
According to the ACPI 6.3 specification, the _PSD method is optional
when using CPPC. The underlying assumption is that each CPU can change
frequency independently from all other CPUs; _PSD is provided to tell
the OS that some processors can NOT do that.
However, the acpi_get_psd() function returns ENODEV if there is no _PSD
method present, or an ACPI error status if an error occurs when evaluating
_PSD, if present. This makes _PSD mandatory when using CPPC, in violation
of the specification, and only on Linux.
This has forced some firmware writers to provide a dummy _PSD, even though
it is irrelevant, but only because Linux requires it; other OSPMs follow
the spec. We really do not want to have OS specific ACPI tables, though.
So, correct acpi_get_psd() so that it does not return an error if there
is no _PSD method present, but does return a failure when the method can
not be executed properly. This allows _PSD to be optional as it should
be.
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/acpi/custom_method.c')
0 files changed, 0 insertions, 0 deletions