Could any of the more knowledgeable on here explain why
is it such a bad idea please?
Because there's no handshaking between the firmware and the OS driver,
and accesses to hardware sensors are often indexed. Imagine this
scenario:
ACPI lmsensors
---- ---------
select temperature register
select fan speed register
read value
read value
ACPi will read the fan speed register instead of the temperature
register, and the value may be far too high and cause a critical
shutdown of the system.
That's the *good* outcome. The bad outcome involves these register
accesses racing in a way that disables fan control or thermal trip
points and risks causing hardware damage. It's not safe for two
different codepaths to access the same hardware without having any kind
of locking, so if your system firmware declares that ACPI is using the
temperature device the hardware sensors framework will refuse to.
All noted, thanks for the explanation - pretty hairy stuff! The tragic
thing is, I have no way of telling ACPI to *not* use or "implement" its
own fan, voltage, temperature management and let a more capable piece of
software (the f71882fg driver in this case) do that job!
What is the alternative? There is none that I could see. I tried using
memmap to force ACPI not to use the memory region claimed by f71882fg
(0x290 - 8 bytes long according to the driver), but that didn't help
much. What am I supposed to do - deactivate ACPI completely? That would
be like going after a fly with a bazooka!
--
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
