ACPI / CPPC: do not require the _PSD method when using CPPC
PATCH v3 1/1 ACPI / CPPC: do not require the _PSD method when using CPPC
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.
v3:
-- bodged the simplification in v2; simplified it properly this time -- verified all error statuses are handled
v2:
-- verified simple check for AE_NOT_FOUND was sufficient -- simplified return status check per Rafael's suggestion
--- drivers/acpi/cppc_acpi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/acpi/cppc_acpi.c +4 -2
@@ -365,8 +365,10 @@ static int acpi_get_psd(struct cpc_desc *cpc_ptr, acpi_handle handle)union acpi_object *psd =NULL ;struct acpi_psd_package *pdomain; - status =acpi_evaluate_object_typed (handle,"_PSD" ,NULL , &buffer, -ACPI_TYPE_PACKAGE ); + status =acpi_evaluate_object_typed (handle,"_PSD" ,NULL , + &buffer,ACPI_TYPE_PACKAGE ); +if (status ==AE_NOT_FOUND )/* _PSD is optional */ +return 0 ;if (ACPI_FAILURE (status))return -ENODEV ;
Signature · 1 line
2.21.0