Hi Jean, Apologies for my late reply too :) > Date: Tue, 27 Jan 2009 10:44:00 +0100 [...] > > The fact that it didn't work with the IDE could just be because I'm so > > clueless! Does the fact that the IDE controller has a function number > > other than 0 affect the way the DECLARE_PCI_FIXUP_HEADER() macro is used > > or what is passed to the hook function? Even if not, if you think using > > the IDE is preferable I can have another try in case it didn't work due > > to a stupid mistake. > > Yes, I would like you to try again with the IDE device, because there's > only one IDE device and 3 USB devices so using the IDE device should be > more efficient (quirk runs only once.) That makes sense! Now that I look more closely, I guess the 3 USB devices each have their own ID, though, so it wouldn't be so bad: 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) (prog-if 00 [UHCI]) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) (prog-if 00 [UHCI]) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) (prog-if 20 [EHCI]) i.e. 24c2 would only pick up the first one. > No, the function number shouldn't play any role. I can't see any reason > why IDE wouldn't work. I tried again and I guess it is an ordering issue - the special bit has to be set in the ISA bridge which is at 00:1f.0 but the IDE controller is at 00:1f.1 so the function that sets 'asus_hides_smbus' is called after the function that checks it. I used '#define DEBUG 1' and 'dmesg' to verify: >>> pci 0000:00:1f.0: calling acpi_pm_check_graylist+0x0/0x2d * The chipset may have PM-Timer Bug. Due to workarounds for a bug, * this clock source is slow. If you are sure your timer does not have * this bug, please use "acpi_pm_good" to disable the workaround pci 0000:00:1f.0: calling old_ich_force_enable_hpet_user+0x0/0x20 HPET not enabled in BIOS. You might try hpet=force boot option pci 0000:00:1f.0: calling asus_hides_smbus_lpc+0x0/0xa6 pci 0000:00:1f.0: calling quirk_ich4_lpc_acpi+0x0/0x65 pci 0000:00:1f.0: quirk: region f800-f87f claimed by ICH4 ACPI/GPIO/TCO pci 0000:00:1f.0: quirk: region fa00-fa3f claimed by ICH4 GPIO pci 0000:00:1f.0: calling pci_fixup_transparent_bridge+0x0/0x2b PCI: 0000:00:1f.1 reg 10 io port: [24b0, 24b7] PCI: 0000:00:1f.1 reg 14 io port: [24c0, 24c3] PCI: 0000:00:1f.1 reg 18 io port: [24b8, 24bf] PCI: 0000:00:1f.1 reg 1c io port: [24c4, 24c7] PCI: 0000:00:1f.1 reg 20 io port: [24a0, 24af] PCI: 0000:00:1f.1 reg 24 32bit mmio: [0, 3ff] pci 0000:00:1f.1: calling asus_hides_smbus_hostbridge+0x0/0x22e pci 0000:00:1f.1: quirk: FIXME: FOUND IDE, THIS IS A COMPAQ EVO, SETTING asus_hides_smbus = 1 pci 0000:00:1f.1: calling pci_fixup_transparent_bridge+0x0/0x2b <<< asus_hides_smbus_lpc() is of course the function that checks 'asus_hides_smbus' and you can see it is called before we got to the point where it was set. As you can see from earlier in the mail, the USB controllers are at 00:1d so they come before the ISA bridge and I guess that's why using one of them worked for me! Given that they each have their own ID would it be okay to use them then? Thanks again for your help! Regards, David _________________________________________________________________ Get rid of those unwanted christmas presents! Get what you want at ebay. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Frover%2Eebay%2Ecom%2Frover%2F1%2F705%2D10129%2D5668%2D323%2F4%3Fid%3D10&_t=763807330&_r=hotmailTAGLINES&_m=EXT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20090301/1b255f73/attachment.html
