acpi_throttle: quirk based on pci info

[Andriy Gapon]

on 25/02/2008 19:59 Nate Lawson said the following:
> 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,
these are very good points. It seems that I wrote something very
specific to my case and didn't consider other scenarios. I completely
forgot about SMP case.
I need to think more about this.
A possible blanket solution would be to probe/attach all and any cpu
child devices after pci bus is attached. But I don't know if this is a
viable solution in general and if it's possible to implement at all.

-- 
Andriy Gapon