[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.0912160009100.28497@localhost.localdomain>
Date: Wed, 16 Dec 2009 00:21:39 -0500 (EST)
From: Len Brown <lenb@...nel.org>
To: J.A. Magallón <jamagallon@....com>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org
Subject: Re: Useless thermal acpi driver ?
On Tue, 15 Dec 2009, J.A. Magallón wrote:
> On Mon, 14 Dec 2009 22:00:25 -0500 (EST), Len Brown <lenb@...nel.org> 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
>
> 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 ?
>
Check, for an updated BIOS from the vendor.
If there is none, then express your displeasure to the vendor
and consider a different one for your next purchase.
For the box you have, try "acpi_enforce_resources=lax"
and load your native sensor driver.
Likely you'll be happy with that -- I just can't guarantee it.
cheers,
-Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists