[lm-sensors] ACPI versus native IC drivers
Hans de Goede
hdegoede at redhat.com
Thu Jan 1 23:06:59 CET 2009
I've made a good start with reviewing the new ATK0110 driver. And I must say I
like it. But, there is a big but.
On my Asus M2N SLI Deluxe motherboard, with this driver loaded the two hwmon
IC's on this board (one superio, one smbus) get hit by both the ACPI and native
driver code. This is bad, really bad!
Luckily I can fix this by:
1) Using Jean's queued patch for adding acpi resource checks to superio drivers
2) Specifying: "acpi_enforce_resources=strict" on the command line
With this, the native drivers will no longer load. As we have no idea what the
ACPI code is doing (it might be updating the readings periodically based on a
timer for all we know). To me this (causing the native drivers to no longer
load) seems to be the right solution.
The patch adding these checks to the super-io drivers is already queued for
2.6.29. But that won't help as the current behaviour is to only warn when there
is a conflict.
So I would like to suggest to change the default setting for
acpi_enforce_resources from nag to strict. This will only impact smbus
controllers and superio hwmon code as those are the only 2 using it.
I would personally like to take things even further and believe it would be
correct to do an acpi resource check with warning level only in the low level
resource alloc. code for all resource allocation. But that is a different
Back on topic, there is one big "but" here. If we change the default setting
for acpi_enforce_resources to strict, then this will cause problems for people,
and those problems will get seen as regressions. For example many asus users
will stop having functional sensors (atleast in my asus board ACPI claims the
relevant resources for accessing the sensors). Still I think we should make the
default strict, as that seems the right thing to do. As this is an option
people can always change the option as a work around if this causes too much pain.
Making this option strict by default is the only safe way I see for ever
allowing the atk0110 driver in to the mainline kernel.
More information about the lm-sensors