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]

Date:	Fri, 22 May 2009 13:50:59 +0200
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Peter Feuerer <peter@...e.net>, 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,

>>> the more I'm looking at the driver, the more I get annoyed by that
>>> user/kernel mode operation split. Remind me again why the driver should
>>> be loaded and not started automatically but the user should be required
>>> to activate it explicitly?
>>
>> The idea of not starting the module in kernel mode was from Matthew. And
>> he stated that it could harm the hardware when software controls the fan
>> instead of the BIOS. It may also be possible, that the warranty gets
>
> Well... hw is usually designed to protect itself.

It seems like the fan in the aspire one's is used for cooling the
surrounding devices too and while the thermal envelope of the CPU is
much wider, the peripherals are much more susceptible to temperatures
outside of their allowed operating range. That's why currently the
driver lets the BIOS control the fan since its settings are most
conservative.

>>> That's not so optimal, I'd say. The kernel module should _replace_
>>> the userspace program, not work alongside it, since the last is flaky
>>> and unreliable, and this was the main reason the kernel module was
>>> introduced in the first place - to control the fan from kernel space,
>>> which is the more sane choice.
>>
>> The main reason to do this in kernel was the availabilty of atomic ec-
>> read and write functions. But I agree with you that either kernel or BIOS
>> should control the fan and not a userspace tool. I added the user mode
>> just because it wasn't really much more code than just an implementation
>> of the enable/disable functionality.
>
> Kernels crash, too, just like userspace does. It would still make
> sense to allow userspace to increase fan speed.

Well, if the kernel is dead, userspace has already died too. Besides,
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.

-- 
Regards/Gruss,
Boris
--
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/