Re: [patch 1/3] acpi: check _PSS invalidation when BIOS report _PSS with 0x80000000

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Thu, May 14, 2009 at 01:35:10PM -0400, Len Brown wrote:
> NAK
> 
> This is a recording.
> 
> Andrew, please remove this patch from your series
> per issues earlier discussed on the list.

On the dump I have from a machine showing this issue, we'd fail 
gracefully if we checked the return value of 
acpi_processor_preregister_performance() as the coordination type is set 
to an invalid value. Are there any cases where this fails and the 
hardware still works? If not, then:

diff --git a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
index 208ecf6..fbb8e59 100644
--- a/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -561,7 +561,11 @@ static int __init acpi_cpufreq_early_init(void)
 	}
 
 	/* Do initialization in ACPI core */
-	acpi_processor_preregister_performance(acpi_perf_data);
+	if (acpi_processor_preregister_performance(acpi_perf_data)) {
+		free_acpi_perf_data();
+		return -EINVAL;
+	}
+
 	return 0;
 }
 
would seem to be correct. The alternative is that the number of 
processors is also set to 0x80000000 - according to the spec "OSPM will 
not start performing power state transitions to a particular P-state 
until this number of processors belonging to the same domain have been 
detected and started". Since we're clearly never reaching that 
condition, why is the governor even getting started?

-- 
Matthew Garrett | mjg59@srcf.ucam.org