public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockrwd@gmail.com>
To: "\"J.A. Magallón\"" <jamagallon@ono.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: Useless thermal acpi driver ?
Date: Mon, 21 Dec 2009 19:06:11 -0600	[thread overview]
Message-ID: <4B301B83.1010207@gmail.com> (raw)
In-Reply-To: <20091215234619.62d0ebc1@werewolf.home>

On 12/15/2009 04:46 PM, J.A. Magallón wrote:
> On Mon, 14 Dec 2009 22:00:25 -0500 (EST), Len Brown<lenb@kernel.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

You can return to the "old way", that's what acpi_enforce_resources=lax 
is for. It won't be any more dangerous than it was before. The problem 
is that there's no way (at least, no simple one, it seems) to know if 
the BIOS is really going to access those registers it indicates it 
might. There are systems where it indeed does access them and this 
breaks things badly (causing problems like spurious thermal shutdowns).

What is the error that prevents w83627hf from loading? It might be 
useful to find what reference in the AML causes the detection that it 
may access the device registers.
	
>
> 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 ?

It wouldn't make any sense. An ACPI driver would have to access some 
interface that the BIOS ACPI AML code provides to access the sensor 
data. Presumably this BIOS doesn't provide such an interface. (The only 
such interface other than the standard ACPI thermal zone interface that 
I'm aware of is the ATK0110 interface used on a lot of Asus motherboards.)

      parent reply	other threads:[~2009-12-22  1:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09 22:26 Useless thermal acpi driver ? J.A. Magallón
2009-12-10  1:00 ` Robert Hancock
2009-12-11  6:25   ` Len Brown
2009-12-11  8:45     ` J.A. Magallón
2009-12-15  3:00       ` Len Brown
2009-12-15 22:46         ` J.A. Magallón
2009-12-16  5:21           ` Len Brown
2009-12-22  1:06           ` Robert Hancock [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B301B83.1010207@gmail.com \
    --to=hancockrwd@gmail.com \
    --cc=jamagallon@ono.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox