[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070527215123.GA22687@srcf.ucam.org>
Date: Sun, 27 May 2007 22:51:23 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Pavel Machek <pavel@....cz>
Cc: Thomas Renninger <trenn@...e.de>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org
Subject: Re: 2.6.22-rc1-mm1 Implementing fan/thermal control in userspace - Was: [cannot change thermal trip points]
On Fri, May 25, 2007 at 06:38:15AM +0000, Pavel Machek wrote:
> Hi!
> > Because, as Len has pointed out, you end up with two different ideas
> > about what the trip points are - the kernel's and the hardware's. That
> > works fine until some event in the firmware either forcibly
> > resynchronises the two or makes assumptions about the spec-compliance of
> > the interpreter.
>
> ...and suggested workaround is to drive fans directly from userspace,
> which not only violates the specs and has all the problems with
> desynchronized state, but ALSO FAILS TO WORK IN PRACTICE.
I don't think that's obviously true. 11.3.2 of the 3.0 spec states:
"A package consisting of references to all active cooling devices that
should be engaged when the associated active cooling threshold (_ACx) is
exceeded."
(referring to _ALx objects).
> > The interface would need to be more complicated than that if you wanted
> > to be able to implement hysteresis, and there's the potential for
> > hardware damage if paramaters are set inappropriately. Even then,
> > there's no easy way of programatically determining whether it would work
> > on any given hardware.
>
> Not sure why you try to scare people with 'hardware damage'. HP XE3
> bios already _was_ damaging hardware (it cooked the hard drive using
> cpu as a heater), and no acpi magic can damage correctly working
> machine.
Given that this presumably didn't occur under Windows, I think it would
be significantly better to figure out why and then fix that.
Alternatively, if the firmware tables are actually genuinely broken in a
way that's impossible to repair, you can replace the table. That has the
advantage that there's no risk of the platform and the OS becoming
confused.
--
Matthew Garrett | mjg59@...f.ucam.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists