[ltp] [patch 11/12][2.6.18] ibm-acpi: workaround for EC 0x2f initialization bug

[Henrique de Moraes Holschuh]

On Mon, 23 Oct 2006, Shem Multinymous wrote:
> On 10/23/06, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> >There is another option.  I can overengineer the thing.  I can read all
> >thermal sensors, and if all sensors are within some safe range (say, below
> >60 C), kick the fan to mode auto.  If they are outside that range, kick the
> >fan to mode 0x07.
> 
> That's dangerous; for one, nothing guarantees we see all sensors. It's
> best done by userspace, if at all.

Well, not really.  First, we *do* see all sensors, this is a codepath
restricted to specific models after all.  This path doesn't have to be
future-proof, it just needs to be misguided-kernel-hacker-proof.

Second, changing fan speed in userspace can be at best just as dangerous, as
nobody will want to do it manually at every boot.  So, I assume you mean
giving the local admin a choice of doing *nothing* (and thus remain with
status unknown until the next sleep that does not resume in a thermal alarm
condition), which is indeed safer.

Well, reverting the bug workaround is not really a problem, just a cosmetic
thing.  But this talk brought something back that I intended to discuss and
forgot about: the safety of the watchdog and of the fan "enable" command.

Fan enable for ibm-acpi is (and has always been) just the same as "level
auto" on the thinkpads where level auto is supported, and I extended it to
do "level 7" on the thinkpads where it is not supported.

The problem is obvious: if we cannot blindly set the fan to mode auto, then
fan enable is not safe.

I should say I am not really too worried, as the EC should be able to bump
the fan up to level 7 in auto mode, but since there is code in the DSDT to
set level 0x07 by force, I have a tendency to take the safe path.

Just a note: I am not sure *any* of the thermal conditioning code in the
DSDT is active under Linux for the T43.  Almost all of it seems to depend on
stuff that gets set depending on the version of *windows*, and not much of
it has "else" clauses that get run on Linux!

I can add the thermal safety net to fan enable (it will make it safer, no
matter how you look at it).  Should I?

Here's the proposed chages to "fan enable":
	1. If fan level is known and it is 0x07, set it again to 0x07
	2. If any of the thermal sensors if above a user-defined
	   per sensor threshold (default: all sensors to 60 C),
	   set to fan level 0x07
	3. Otherwise, set it to auto

At which point, I'd say the proper work around for the unknown fan status
bug is to just do a fan enable at module load.

The other possibility is to change fan enable to always set the speed to
0x07, which is always annoying, but always safe.  This can't be used for the
workaround, but it is good for the watchdog.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh