Re: 2.6.22 regression: thermal trip points

[Thomas Renninger]

On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
> On Thu, Aug 02, 2007 at 12:02:21PM +0100, Alan Cox wrote:
> > > Anyway, only solution/workaround to use these machines with current
> > > kernels is to override trip points, maybe the patch should really just
> > > be reverted...
> > 
> > The question really is whether the vendors will all revert it and carry
> > it as a patch or whether the main tree will accept reality on this one.
> > 
> > Reverting it and adding a taint marker if you do it is much preferable I
> > suspect to having every vendor revert this bogus if well meaning
> > changeset.
> 
> I strongly suspect that the vast majority[1] of hardware that "needs" 
> the trip points changing works perfectly well under Windows, so it's 
> likely to be papering over bugs in the kernel. It'd be nice if we fixed 
> those rather than encouraging people to poke stuff into /proc,
Some arguments against that:
  - You cannot tell a customer: Wait for the kernel in half a year.
    This is the time it at least needs until a laptop got sold, the
    problem is found, a patch is written and checked in and finally
    hits the distribution.
  - You can also not backport fixes as ACPI patches mostly have the
    potential to break other machines/BIOSes
  - There also exist the policy to not fix up/workaround totally broken
    AML BIOS implementations
  - We do not need to and never will be able to copy or do the same
    Windows is doing
  - ...    

> especially when doing so is guaranteed to break in really confusing ways 
> with a lot of hardware. The firmware can reset the trip points at 
> essentially arbitrary times and is well within its rights to expect the 
> OS to actually pay attention to them.
What the hell is so wrong with:

Let the user override the trip points. If he does so, ignore
thermal trip point updates from BIOS. Don't care for hysteresis
BIOS implementations (these are the BIOS trip point updates).
If user changes them, it's his fault, he doesn't need to...
Make sure that trip points can only be lowered, compared to the
initially fetched one from BIOS.

This is neither confusing, nor dangerous in any way (beside the fact
that the critical trip point might get dynamically lowered by BIOS,
which is totally insane).

  Thomas

> 
> [1] Some hardware is simply broken. We don't carry phc just because some 
> vendors put the wrong voltage values in their tables, either


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/