From: Borislav Petkov <petkovbb@googlemail.com>
To: Peter Feuerer <peter@piie.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
lenb@kernel.org, Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] Acer Aspire One Fan Control
Date: Tue, 28 Apr 2009 09:25:19 +0200 [thread overview]
Message-ID: <20090428072519.GA12170@liondog.tnic> (raw)
In-Reply-To: <cone.1240858632.795110.5316.1000@onepiie>
Hi Peter,
On Mon, Apr 27, 2009 at 08:57:12PM +0200, Peter Feuerer wrote:
> Hi Boris,
>
> thank you very much for your email.
>
> Borislav Petkov writes:
>
>> I did some testing on my Aspire One machine here and it looks pretty
>> nice: while compiling a kernel watched the fan going on when the
>> temperature reaches 67-68 (I don't think this is Celsius though, no?)
>> and then turning itself off when temp goes below 60.
>
> It is Celsius, the specification of the chipset and the atom core say
> that the chips are allowed to get 99 degree celsuis hot. So I think 70
> degree Celsius are fine.
Their N270 datasheet
(http://download.intel.com/design/processor/datashts/320032.pdf) talks
about max Tj (junction temperature) being 90°C for a TDP of 2.5W and if
you operate below that limit "functionality and long-term reliability
can be expected." :)
There's also an internal termtrip sensor which is designed to go off at
Tj=125°C so, yeah, I guess something 70°C should be ok.
>>>
>>> +config ACERHDF
>>> + tristate "Acer Aspire One temperature and fan driver"
>>> + depends on THERMAL
>>> + depends on THERMAL_HWMON
>>
>> depends on THERMAL && THERMAL_HWMON
>
> What do you mean? Sorry, don't get it.
just put the two terms on one line instead of declaring them separately.
>>> +/* module parameters */
>>> +module_param(interval, int, 0600);
>>> +MODULE_PARM_DESC(interval, "Polling interval of temperature check");
>>> +module_param(fanon, int, 0600);
>>
>> This allows for the user to potentially melt his CPU by entering a too high
>> value. You should check that in the acerhdf_init() against the max allowed
>> according to spec, I gather it is 67?
>
> I will add a maximum temperature, I guess something about 80 degree
> Celsuis. But anyways, the user can still melt his/her cpu by switching to
> user mode and turning off the fan.
That's true, the user can do all sorts of damages to the machine but
I think it is sensible to catch honest mistakes like mistyping the
temperature and then unwillingly killing your hardware.
And yes, you shouldn't use the max allowed temp Tj=90 according to
the spec which could turn out to be bad choice due to imprecise
measurements/latent reaction of software. Instead, a nice safety gap of
about 10° is needed so 80 sounds good.
>>> +struct bios_settings_t {
>>> + const char *vendor;
>>> + const char *version;
>>> + unsigned char fanreg;
>>> + unsigned char tempreg;
>>> + unsigned char cmd_off;
>>> + unsigned char cmd_auto;
>>> + unsigned char state_off;
>>
>> obviously cmd_off and state_off are the same values so remove one of them.
>
> I think it makes sense to leave it this way, because we don't know, what
> acer does for the next BIOS release :)
yes, however, let's do it only when they change it instead of predicting the
future :)
[..]
>>> + /* if started in user mode, prevent the kernel from switching
>>> + * off the fan */
>>> + if (!kernelmode) {
>>> + recently_changed = 1;
>>> + printk(KERN_NOTICE
>>> + "acerhdf: kernelmode disabled\n");
>>> + printk(KERN_NOTICE
>>> + "acerhdf: to enable kernelmode:\n");
>>> + printk(KERN_NOTICE
>>> + "acerhdf: echo -n \"enabled\" > "
>>> + "/sys/class/thermal/thermal_zone0/mode\n");
>>
>> maybe I'm missing something but shouldn't this be enabled by default and
>> only when the user wants to have acerfand or some other uspace tool do
>> the controlling, only then turn it off. I'd rather trust this is done
>> in the kernel instead of some flaky uspace thread which could maybe
>> segfault and we fry our nice little netbook :).
>
> Matthew suggested to start the module in usermode, where the BIOS takes
> care about the fan as long as there is no userspace tool or the user want
> the kernel to care about the fan.
But when the BIOS "takes care" of the fan, it boils down to the last being
always on, no? I'd rather have it when the fan is controlled by the kernel
module and gets turned on only when its trip temperature is exceeded.
Thanks.
--
Regards/Gruss,
Boris.
next prev parent reply other threads:[~2009-04-28 7:25 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-25 1:45 Peter Feuerer
2009-04-25 8:42 ` Peter Feuerer
2009-04-26 15:31 ` Matthew Garrett
2009-04-27 18:25 ` Peter Feuerer
2009-04-26 17:29 ` Borislav Petkov
2009-04-27 18:57 ` Peter Feuerer
2009-04-28 7:25 ` Borislav Petkov [this message]
2009-04-28 10:04 ` Maxim Levitsky
2009-04-28 20:17 ` Peter Feuerer
2009-04-28 20:31 ` Maxim Levitsky
2009-05-02 21:21 ` Peter Feuerer
2009-05-03 18:46 ` Borislav Petkov
2009-05-06 19:41 ` Peter Feuerer
2009-05-06 22:17 ` Peter Feuerer
2009-05-09 17:14 ` Borislav Petkov
2009-05-11 18:05 ` Peter Feuerer
2009-05-12 6:02 ` Borislav Petkov
2009-05-18 18:04 ` Peter Feuerer
2009-05-18 20:20 ` Joe Perches
2009-05-19 6:47 ` Peter Feuerer
2009-05-19 7:06 ` Joe Perches
2009-05-24 19:22 ` Borislav Petkov
2009-06-01 14:12 ` Peter Feuerer
2009-06-03 7:35 ` Borislav Petkov
2009-06-03 8:10 ` Peter Feuerer
2009-06-03 10:52 ` Borislav Petkov
2009-06-03 11:29 ` Peter Feuerer
2009-06-03 13:07 ` Peter Feuerer
2009-06-03 14:49 ` Borislav Petkov
2009-06-01 14:18 ` Peter Feuerer
2009-06-03 7:39 ` Borislav Petkov
2009-06-03 7:52 ` Peter Feuerer
2009-06-03 8:00 ` Borislav Petkov
2009-05-19 20:30 ` Pavel Machek
2009-05-22 11:50 ` Borislav Petkov
2009-05-22 14:09 ` Pavel Machek
2009-05-22 14:53 ` Borislav Petkov
2009-05-24 11:13 ` Peter Feuerer
2009-05-22 16:10 ` [PATCH] Acer Aspire One Fan Contro Andreas Mohr
2009-05-22 18:24 ` Borislav Petkov
2009-05-22 19:35 ` Andreas Mohr
2009-04-26 22:20 ` [PATCH] Acer Aspire One Fan Control Joe Perches
2009-04-27 19:03 ` Peter Feuerer
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=20090428072519.GA12170@liondog.tnic \
--to=petkovbb@googlemail.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=peter@piie.net \
--cc=petkovbb@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®