On 12/15/2009 04:46 PM, J.A. Magallón wrote:
On Mon, 14 Dec 2009 22:00:25 -0500 (EST), Len Brown<lenb@xxxxxxxxxx> wrote:this DSDT returns a constant temperature, always: Method (_TMP, 0, NotSerialized) { Return (0x0BB8) } so in this case, Linux is just reporting the (lack of) news:-)So, lets see...: - Someone decided ACPI is the only-real-good-way - Only a few devices are ported to ACPI - The old way is unusable - We can not return to the old way
You can return to the "old way", that's what acpi_enforce_resources=lax is for. It won't be any more dangerous than it was before. The problem is that there's no way (at least, no simple one, it seems) to know if the BIOS is really going to access those registers it indicates it might. There are systems where it indeed does access them and this breaks things badly (causing problems like spurious thermal shutdowns).
What is the error that prevents w83627hf from loading? It might be useful to find what reference in the AML causes the detection that it may access the device registers.
So, any solution ? Thermal ACPI info in this boards (and I suspect in many others) is useless. We can not disable that part of ACPI, we can not enable sensors. So no thermal monitoring. Nice. Ayways, as in this case the ACPI part does not any real work, is still present the problem of two drivers poking the same hardware or could I use that 'lax' trick ? And second, can the traditional sensor drivers be ported to offer an ACPI device replacing the default one, or is that a stupid question ?
It wouldn't make any sense. An ACPI driver would have to access some interface that the BIOS ACPI AML code provides to access the sensor data. Presumably this BIOS doesn't provide such an interface. (The only such interface other than the standard ACPI thermal zone interface that I'm aware of is the ATK0110 interface used on a lot of Asus motherboards.)
-- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
