All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Zintakis <michael.zintakis@googlemail.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	lm-sensors@lm-sensors.org, Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org
Subject: Re: [lm-sensors] Fintek f71882fg ACPI conflict
Date: Thu, 28 Jun 2012 12:15:43 +0100	[thread overview]
Message-ID: <4FEC3CDF.7050901@googlemail.com> (raw)
In-Reply-To: <20120628014548.GA15994@srcf.ucam.org>


>> 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!

WARNING: multiple messages have this Message-ID (diff)
From: Michael Zintakis <michael.zintakis@googlemail.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	lm-sensors@lm-sensors.org, Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org
Subject: Re: [lm-sensors] Fintek f71882fg ACPI conflict
Date: Thu, 28 Jun 2012 11:15:43 +0000	[thread overview]
Message-ID: <4FEC3CDF.7050901@googlemail.com> (raw)
In-Reply-To: <20120628014548.GA15994@srcf.ucam.org>


>> 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!

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2012-06-28 11:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-26 23:56 [lm-sensors] Fintek f71882fg ACPI conflict Michael Zintakis
2012-06-27 17:15 ` Guenter Roeck
2012-06-27 17:15   ` [lm-sensors] " Guenter Roeck
2012-06-27 23:00   ` Michael Zintakis
2012-06-27 23:00     ` Michael Zintakis
2012-06-28  1:45     ` Matthew Garrett
2012-06-28  1:45       ` Matthew Garrett
2012-06-28 11:15       ` Michael Zintakis [this message]
2012-06-28 11:15         ` Michael Zintakis
2012-06-28 12:40         ` Jean Delvare
2012-06-28 12:40           ` Jean Delvare
2012-06-28 12:53           ` Michael Zintakis
2012-06-28 12:53             ` Michael Zintakis
2012-06-28 13:27             ` Jean Delvare
2012-06-28 13:27               ` Jean Delvare
2012-06-29  5:35               ` Robert Hancock
2012-06-29  5:35                 ` Robert Hancock
2012-06-29 12:11                 ` Michael Zintakis
2012-06-29 12:11                   ` Michael Zintakis
2012-06-29 16:34                   ` Guenter Roeck
2012-06-29 16:34                     ` Guenter Roeck
2012-06-28  5:20     ` Guenter Roeck
2012-06-28  5:20       ` Guenter Roeck
2012-06-28 11:31       ` Michael Zintakis
2012-06-28 11:31         ` Michael Zintakis
2012-06-28 17:12         ` Guenter Roeck
2012-06-28 17:12           ` Guenter Roeck
2012-06-28 17:39           ` Michael Zintakis
2012-06-28 17:39             ` Michael Zintakis
2012-06-28 18:57             ` Guenter Roeck
2012-06-28 18:57               ` Guenter Roeck
2012-06-28  3:15 ` Andrey Repin
2012-06-28 11:36 ` Michael Zintakis

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=4FEC3CDF.7050901@googlemail.com \
    --to=michael.zintakis@googlemail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mjg59@srcf.ucam.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.