From: Krzysztof Helt <[email protected]>
This patch unhides the SMBus on Compaq Deskpro EN
SFF P667 with the Intel 815E chipset. Unhiding it reveals
a THMC51 hardware monitoring chip.
Jean Delvare has checked that this machine has no ACPI
magic touching the SMBus nor the hardware monitoring chip,
so this should be safe.
The patch was tested on Fedora Core 9 with 2.6.25.4 kernel.
Signed-off-by: Krzysztof Helt <[email protected]>
Tested-by: Rafa? Ha?aduda <[email protected]>
CC: Jean Delvare <[email protected]>
---
If someone owns the Compaq Deskpro EN machine, please
test the patch as well.
diff -urp linux-2.6.25/drivers/pci/quirks.c linux-new/drivers/pci/quirks.c
--- linux-2.6.25/drivers/pci/quirks.c 2008-05-27 21:58:34.380144607 +0200
+++ linux-new/drivers/pci/quirks.c 2008-05-30 23:12:57.510219450 +0200
@@ -1054,6 +1054,14 @@ static void __init asus_hides_smbus_host
* its on-board VGA controller */
asus_hides_smbus = 1;
}
+ else if (dev->device == PCI_DEVICE_ID_INTEL_82815_CGC)
+ switch (dev->subsystem_device) {
+ case 0x001A: /* Compaq Deskpro EN SSF P667 815E */
+ /* Motherboard doesn't have host bridge
+ * subvendor/subdevice IDs, therefore checking
+ * its on-board VGA controller */
+ asus_hides_smbus = 1;
+ }
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845_HB, asus_hides_smbus_hostbridge);
@@ -1068,6 +1076,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82915GM_HB, asus_hides_smbus_hostbridge);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG3, asus_hides_smbus_hostbridge);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_CGC, asus_hides_smbus_hostbridge);
static void asus_hides_smbus_lpc(struct pci_dev *dev)
{
On Sunday, June 08, 2008 4:47 am Krzysztof Helt wrote:
> From: Krzysztof Helt <[email protected]>
>
> This patch unhides the SMBus on Compaq Deskpro EN
> SFF P667 with the Intel 815E chipset. Unhiding it reveals
> a THMC51 hardware monitoring chip.
>
> Jean Delvare has checked that this machine has no ACPI
> magic touching the SMBus nor the hardware monitoring chip,
> so this should be safe.
>
> The patch was tested on Fedora Core 9 with 2.6.25.4 kernel.
>
> Signed-off-by: Krzysztof Helt <[email protected]>
> Tested-by: Rafa? Ha?aduda <[email protected]>
> CC: Jean Delvare <[email protected]>
Thanks Krzysztof; applied to linux-next. I had to fix up a conflict by hand
though, would be good if you could double check it.
Thanks,
Jesse
Hi Jesse, hi Krzysztof,
On Tue, 10 Jun 2008 12:02:19 -0700, Jesse Barnes wrote:
> On Sunday, June 08, 2008 4:47 am Krzysztof Helt wrote:
> > From: Krzysztof Helt <[email protected]>
> >
> > This patch unhides the SMBus on Compaq Deskpro EN
> > SFF P667 with the Intel 815E chipset. Unhiding it reveals
> > a THMC51 hardware monitoring chip.
> >
> > Jean Delvare has checked that this machine has no ACPI
> > magic touching the SMBus nor the hardware monitoring chip,
> > so this should be safe.
Let it be noted that ACPI is only one of the possible offenders. SMM is
another one. The user reported that his fan speed was changing speeds so
something has to be acting upon temperature changes. This could be the
fan itself, or this could be SMM code changing the registers of the
chip.
At this point of the investigation, I am still not 100% sure that the
patch is safe. I'd say it is only safe if the user's fan is actually
self-regulated based on the temperature.
One easy way to test would be to verify what happens when the
temperature exceeds 53 degrees C (the high temperature limit) and 78
degrees C (the critical temperature limit). Typical SMM code would
change the high and low limits when the high limit is crossed, this
should be clearly visible in the output of "sensors".
BTW, Krzysztof, what about adding (read-only) support for the critical
limits to your thmc50 driver? It would be helpful in a situation like
this.
Another thing to check is whether the value of register 0x19 (analog
output) changes automatically when the fan speeds up.
Until these tests are done, I consider this patch possibly unsafe and
not ready to go to Linus (although probably OK for -next).
> > The patch was tested on Fedora Core 9 with 2.6.25.4 kernel.
> >
> > Signed-off-by: Krzysztof Helt <[email protected]>
> > Tested-by: Rafał Haładuda <[email protected]>
> > CC: Jean Delvare <[email protected]>
>
> Thanks Krzysztof; applied to linux-next. I had to fix up a conflict by hand
> though, would be good if you could double check it.
>
> Thanks,
> Jesse
--
Jean Delvare
On Wednesday, June 11, 2008 7:53 am Jean Delvare wrote:
> Hi Jesse, hi Krzysztof,
>
> On Tue, 10 Jun 2008 12:02:19 -0700, Jesse Barnes wrote:
> > On Sunday, June 08, 2008 4:47 am Krzysztof Helt wrote:
> > > From: Krzysztof Helt <[email protected]>
> > >
> > > This patch unhides the SMBus on Compaq Deskpro EN
> > > SFF P667 with the Intel 815E chipset. Unhiding it reveals
> > > a THMC51 hardware monitoring chip.
> > >
> > > Jean Delvare has checked that this machine has no ACPI
> > > magic touching the SMBus nor the hardware monitoring chip,
> > > so this should be safe.
>
> Let it be noted that ACPI is only one of the possible offenders. SMM is
> another one. The user reported that his fan speed was changing speeds so
> something has to be acting upon temperature changes. This could be the
> fan itself, or this could be SMM code changing the registers of the
> chip.
>
> At this point of the investigation, I am still not 100% sure that the
> patch is safe. I'd say it is only safe if the user's fan is actually
> self-regulated based on the temperature.
>
> One easy way to test would be to verify what happens when the
> temperature exceeds 53 degrees C (the high temperature limit) and 78
> degrees C (the critical temperature limit). Typical SMM code would
> change the high and low limits when the high limit is crossed, this
> should be clearly visible in the output of "sensors".
>
> BTW, Krzysztof, what about adding (read-only) support for the critical
> limits to your thmc50 driver? It would be helpful in a situation like
> this.
>
> Another thing to check is whether the value of register 0x19 (analog
> output) changes automatically when the fan speeds up.
>
> Until these tests are done, I consider this patch possibly unsafe and
> not ready to go to Linus (although probably OK for -next).
Ok, thanks for the heads up Jean, I'll keep this one out of the queue I send
to Linus until we get confirmation about its safety.
Thanks,
Jesse
On Wed, 11 Jun 2008 09:16:38 -0700
Jesse Barnes <[email protected]> wrote:
> On Wednesday, June 11, 2008 7:53 am Jean Delvare wrote:
> > BTW, Krzysztof, what about adding (read-only) support for the critical
> > limits to your thmc50 driver? It would be helpful in a situation like
> > this.
> >
I'll try to add this and support for adm1028/thmc51 chips.
> > Another thing to check is whether the value of register 0x19 (analog
> > output) changes automatically when the fan speeds up.
> >
> > Until these tests are done, I consider this patch possibly unsafe and
> > not ready to go to Linus (although probably OK for -next).
>
> Ok, thanks for the heads up Jean, I'll keep this one out of the queue I send
> to Linus until we get confirmation about its safety.
>
I should be able to confirm in about a week. Two guys are currently using
the patch with thmc50 sensor driver.
Regards,
Krzysztof
----------------------------------------------------------------------
Podbij Dziki Zachod!Gra strategiczna online
Sprawdz >>> http://link.interia.pl/f1dff