On 06/28/2012 07:27 AM, Jean Delvare wrote:
On Thu, 28 Jun 2012 13:53:49 +0100, Michael Zintakis wrote:
In the meantime, considering the specifics of my particular case and the
memory regions involved (again, I think they are 0x290-0x297, a total of
8 bytes in length according to the driver, though if someone more
knowledgeable in the f71882fg driver specifics know otherwise, please
feel free to correct this if that assumption is wrong), would it be
possible to manually hack into the ACPI code and forcefully prevent it
from claiming those memory regions and not get involved in "managing"
that particular device?
Not that I know of. That would rather be a question for the ACPI
people, but I'm afraid the answer is that ACPI is supposed to be the
best thing since sliced bread and you should just let it do its stuff
and not ask questions :( I too would love to be able to tell ACPI to
let my hardware monitoring chip (and/or SMBus controller) alone.
The ACPI conflict gets triggered when the BIOS AML code creates an
operation region to access the same device that the driver is trying to
bind to. There apparently are some BIOSes that do this and yet don't use
it to actually access the hardware monitoring chip. In this case there
is no true conflict and the acpi_enforce_resources=lax option is safe to
use. Unfortunately there's really no way for the kernel to tell whether
or not this is the case.
In this case, however, where the BIOS does in fact expose an ACPI
thermal zone and relies on AML code to perform fan control, etc. then it
seems quite likely that it's not safe to access the same hardware
monitoring controller while AML code may be doing so at the same time.
The only way I can see that you could make ACPI "leave the hardware
monitoring chip alone" is to either have the kernel block its accesses
(quite likely breaking all fan/temperature control) or disable ACPI
entirely (in this case the BIOS likely either leaves the fan control in
"run at max speed always" mode or uses SMIs to gain control where needed
to adjust fan speeds, which causes the same concurrent access problem).
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
