acpi_throttle: quirk based on pci info

[Nate Lawson]

Andriy Gapon wrote:
> on 19/02/2008 01:00 Rui Paulo said the following:
>> On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote:
>>
>>> While looking for something else I accidentally noticed that
>>> acpi_throttle has one quirk for some early revisions of PIIX4 chipset
>>> and the quirk is enabled based on PCI info.
>>> I have a newer revision of PIIX4 so the quirk is not applicable in  
>>> my case.
>>>
>>> Nevertheless I noticed that acpi_throttle is initialized before PCI  
>>> bus
>>> driver, so when it calls pci_find_device() it always returns NULL and
>>> quirk is not applied. At least this is what I see in dmesg on my  
>>> machine.
>> I run into a similar problem on my SoC MacBook project and I ended up  
>> using the SMI vendor strings because it was too early in boot in order  
>> to find the PCI devices. The problem here is very similar.
>> Maybe we should try to use SMI vendor strings instead of  
>> pci_find_device()?
> 
> I am not familiar with this approach and I am not sure if that works
> with that type of (quite old) hardware.
> 
> When I worked on something else I remember somebody (maybe Nate)
> recommending me to model my code after ichss:
> sys/dev/cpufreq/ichss.c
> 
> Maybe the same approach could be used here?
> 
> I.e. no identify method for acpi bus.
> Additional device/driver for pci bus.
> pci probe method checks for duplicates and adds the acpi device as a
> child to acpi bus.
> pci probe method sets quirks based on pci info.
> pci probe method runs device_probe_and_attach on the acpi device.
> as a consequence acpi probe and attach (for successful probe) are executed.
> 
> The only unclear issue is where to place the code that is currently in
> (acpi) identify method - should it go to pci identify method or should
> it go to acpi probe method.

Yeah, it's a problem either way.  I remember something like:

1. Separate PCI attachment that adds ACPI device
Guaranteed that PCI is available.  Bad: won't work if loaded after boot 
(not probed)

2. Directly calling device_probe()
Good: works after boot.  Bad: always adds a device even if none present.

You can see the first one in ichss.c.  It's why cpufreq devices are not 
loadable.

-- 
Nate