[lm-sensors] Does ACPI conflict also happen on MS/Windows?

[Jean Delvare]

On Tue, 1 May 2012 16:36:22 +0200, Luca Tettamanti wrote:
> On Tue, May 1, 2012 at 4:07 PM, Ian Pilcher <arequipeno at gmail.com> wrote:
> > On 04/30/2012 09:55 AM, Jean Delvare wrote:
> >> Most likely they would "work", because they simply do not check the
> >> ACPI conflict in the first place. So they run but not reliably, exactly
> >> the same as running Linux with acpi_enforce_resources=lax.
> >
> > On a slightly related note, I've always been a bit bemused by the this
> > message:
> >
> >  If an ACPI driver is available for this device, you should use it
> >  instead of the native driver
> >
> > What is an "ACPI driver"?
> 
> It means a driver that uses the interface exposed by ACPI.
> 
> > Is there any hardware for which ACPI actually provides the same level of
> > information that "legacy" access does?  Every system I've dealt with
> > over the last few years provides a single temperature reading via ACPI
> > (generally CPU surface temperature) -- no other temperatures, no fans,
> > no voltages.
> 
> A single TZ is common, yes. Asus motherboards provide the so called
> ATK0110 interface for reading temps, fans and voltages.

Provided, actually, it seems they are moving away from it.

There are other examples, including acpi_power_meter and many drivers
under drivers/platform/x86 which do expose some hardware monitoring
features based on proprietary BIOS interfaces, sometimes using ACPI,
sometimes not.

That being said, I can't disagree with Ian: in most cases, when you see
the warning message, there is no APCI driver you can use, and this is a
real problem looking for a solution. The ball is in the vendor's court
though.

-- 
Jean Delvare