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 13:13:50 +0200 |
commit | 92402bba4f32c09c976320c08ca39618e29d4908 (patch) | |
tree | 7cfc4671a85afecff43075832ac2595edd2d6fc3 /kernel | |
parent | 51f464d8bce7f7ad8bdcad10f6ff5f3a1ffe7b3b (diff) | |
download | linux-stable-92402bba4f32c09c976320c08ca39618e29d4908.tar.gz linux-stable-92402bba4f32c09c976320c08ca39618e29d4908.tar.bz2 linux-stable-92402bba4f32c09c976320c08ca39618e29d4908.zip |
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 'kernel')
0 files changed, 0 insertions, 0 deletions