summaryrefslogtreecommitdiff
path: root/drivers/acpi/custom_method.c
diff options
context:
space:
mode:
authorAl Stone <ahs3@redhat.com>2019-08-27 18:21:20 -0600
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-10-05 12:27:49 +0200
commit318e486d4ed967187b91957d1683b8e75e2b1ea6 (patch)
tree8428551f72fc59c889b97ef3a2ebefe247a4b87d /drivers/acpi/custom_method.c
parent7ff7d1e7a749843920201489aaed20154eff5a15 (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