acpi_throttle: quirk based on pci info

[Nate Lawson]

Andriy Gapon wrote:
> on 22/02/2008 17:56 Andriy Gapon said the following:
>> Please find attached a patch that makes sure that acpi_thermal is
>> initialized after PCI bus is available, so that it is possible to decide
>> about hardware quirks based on PCI information.
>> The code uses the same approach as ichss does.
>> The patch is tested to work.
> 
> Oops! I attached on older version of the patch, sorry.
> Correct patch is here.
> (parent of acpi_throttle is cpu, not acpi)
> 
>> NOTE: This patch in contaminated! It contains code that forces throttle
>> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance
>> with the chipsets specifications. Some motherboard/bios vendors lie
>> about this value in FADT.
>> If not accepted, this quirk can be easily stripped from the patch as its
>> code is contained in distinct hunks.

Ok, couple comments I think should be addressed before committing:

* This only adds a child to cpu0.  On an SMP machine, we should have a 
device instance attached to each cpu.  On machines where each CPU has 
its own throttling register, this is necessary to program the new rate.

* Is it necessary to add "device_probe_and_attach(child)"?  I guess if 
the child is added after the cpu parent's probe/attach run has 
completed, that could be a problem.

* I'm uncomfortable with moving the whole driver probe under pci.  I'd 
rather the pci probe happen separately and provide information to the 
cpufreq probe.  But I'm not sure this is feasible.  I wonder if John 
might have any advice on how to coordinate between PCI and cpufreq?

-- 
Nate