All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Thomas Renninger <trenn@suse.de>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	"Adrian Schröter" <adrian@suse.de>,
	"Knut Petersen" <Knut_Petersen@t-online.de>,
	linux-kernel@vger.kernel.org, "Andrew Morton" <akpm@osdl.org>,
	pavel@ucw.cz, lenb@kernel.org, "Zhang, Rui" <rui.zhang@intel.com>,
	"Jean Delvare" <khali@linux-fr.org>,
	"Alexey Starikovskiy" <aystarik@gmail.com>
Subject: Re: 2.6.22 regression: thermal trip points
Date: Thu, 2 Aug 2007 12:56:31 +0100	[thread overview]
Message-ID: <20070802115631.GA29735@srcf.ucam.org> (raw)
In-Reply-To: <1186055100.18821.494.camel@queen.suse.de>

On Thu, Aug 02, 2007 at 01:45:00PM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 12:13 +0100, Matthew Garrett wrote:
> > 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.

We have to do so frequently. New hardware often exposes bugs in the 
kernel.

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

The policy has been to attempt to be bug-compatible with Windows 
whenever possible for some time now.

>   - We do not need to and never will be able to copy or do the same
>     Windows is doing

Given that many vendors still only test against Windows, that's exactly 
what we need to do.

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

No, that's not the only reason for notifications. Alteration in hardware 
state may also force a recalculation of trip point (adding a battery to 
a bay rather than a DVD drive may require the platform to be kept at a 
lower temperature)

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

Surely people want this functionality so that they can raise trip 
points?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2007-08-02 11:56 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-02  8:40 2.6.22 regression: thermal trip points Knut Petersen
2007-08-02  8:52 ` Andrew Morton
2007-08-02 10:48   ` Andi Kleen
2007-08-02 11:00     ` Alan Cox
2007-08-02 12:05       ` Andi Kleen
2007-08-02 13:04         ` Alan Cox
2007-08-02 13:16           ` Andi Kleen
2007-08-02 15:57             ` Pavel Machek
2007-08-02 18:38               ` Andi Kleen
2007-08-02 18:40                 ` Matthew Garrett
2007-08-03 11:16                 ` Thomas Renninger
2007-08-03 18:59                   ` Len Brown
2007-08-06  9:55                     ` Pavel Machek
2007-08-07 18:58                       ` Len Brown
2007-08-07 21:49                         ` Pavel Machek
2007-08-13 12:30                           ` Pavel Machek
2007-08-02 15:55     ` Pavel Machek
2007-08-02  9:42 ` Thomas Renninger
2007-08-02  9:45   ` Adrian Schröter
2007-08-02  9:58     ` Thomas Renninger
2007-08-02 11:02       ` Alan Cox
2007-08-02 11:13         ` Matthew Garrett
2007-08-02 11:45           ` Thomas Renninger
2007-08-02 11:56             ` Matthew Garrett [this message]
2007-08-02 12:42               ` Thomas Renninger
2007-08-02 12:55                 ` Matthew Garrett
2007-08-02 11:59           ` Alan Cox
2007-08-02 11:57             ` Matthew Garrett
2007-08-02 12:06               ` Thomas Renninger
2007-08-02 12:15                 ` Matthew Garrett
2007-08-02 12:35                   ` Thomas Renninger
2007-08-02 12:47                     ` Matthew Garrett
2007-08-02 21:56     ` Len Brown
2007-08-02 21:56       ` Len Brown
2007-08-02 11:32   ` Knut Petersen
2007-08-02 12:06     ` Andi Kleen
2007-08-02 13:06       ` Alan Cox
2007-08-02 16:07     ` Pavel Machek
2007-08-02 19:25     ` Krzysztof Halasa
2007-08-02 21:56 ` Len Brown
2007-08-02 21:56   ` Len Brown
2007-08-03 11:43   ` Renato S. Yamane
2007-08-03 18:35     ` Len Brown
2007-08-03 12:53   ` Knut Petersen
2007-08-03 18:30     ` Len Brown

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=20070802115631.GA29735@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=Knut_Petersen@t-online.de \
    --cc=adrian@suse.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=aystarik@gmail.com \
    --cc=khali@linux-fr.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rui.zhang@intel.com \
    --cc=trenn@suse.de \
    /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.