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

[Shem Multinymous]

On 10/24/06, Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:
> > 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.

Right.


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

I mean you can leave it as "unknown", and if anyone's sufficiently
annoyed he write a boot script that checks the temperatures and resets
the fan speed.

In any case, I suggest you first submit the simplest patch which just
prints unknown. Any further kludges are best seperated to later patch,
perhaps after this series is accepted.


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

Ouch. Good point.


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

How about this conservative but more useful variant?
If the fan level register reads 0x07, don't touch it (it's either a
DSDT emergency, or the boot bug, or a someone who's doing manual
control anyway and can run "level auto" instead).
Otherwise set it to 0x80.


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

Yikes! Running the EC on code paths nobody has looked at is rather disturbing.

  Shem