linux-kernel - Re: [PATCH] Acer Aspire One Fan Control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cone.1243163619.528098.4387.1000@deskpiie>
Date:	Sun, 24 May 2009 13:13:39 +0200
From:	Peter Feuerer <peter@...e.net>
To:	Borislav Petkov <petkovbb@...glemail.com>
Cc:	Pavel Machek <pavel@....cz>, petkovbb@...il.com,
	LKML <linux-kernel@...r.kernel.org>, lenb@...nel.org,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [PATCH] Acer Aspire One Fan Control

Hi,

Borislav Petkov writes:

>> Yep, I don't disagree. But I strongly suspect that if you force the
>> fan off and overheat the machine, it will shut down in hardware before
>> doing any damage.
> 
> Yep, however we won't come that far with the current driver since it
> relinquishes control of the fan to the BIOS after a critical temp of
> 89° is reached. I'm still quite unpersuaded about that "magical" number
> since it is 1 degree below the high interval boundary of the juncture
> temperature of the Atom CPU. I would like to have a more reliable source
> for the allowed envelope based not only on the CPU but on the whole
> chipset but can't seem to find any data from Acer on that.

I think we are fine the way it is now. The driver allows to read the 
temperature by default and people who know what they are doing can easily 
enable kernel based fan control.

>>> the module can still be toggled on/off from sysfs. Actually, empirically
>>> measured, there seem to be three states of the fan: off, on and on-max
>>> where you can hear it rotating at max RPM. The kernel module can handle
>>> those completely if you know the respective ACPI EC commands and there's
>>> no need for userspace daemon, IMHO.
>>
>> It would be still nice to let the userspace lower the trip points for
>> maximum flexibility. No need for userspace _daemon_.
> 
> I'm sure Peter wouldn't mind adding some other sysfs entries in future
> versions of the driver controlling exactly that.

You can already change the trip points via the 
/sys/module/acerhdf/parameters/* files on the fly.

cheers,
--peter
--
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/