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  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:	Sun, 21 Dec 2014 11:51:14 -0800
From:	Guenter Roeck <>
To:	Pali Rohár <>,
	Arnd Bergmann <>,
	Greg Kroah-Hartman <>
	Steven Honeyman <>,
	Jean Delvare <>,
	Gabriele Mazzotta <>,
	Jochen Eisinger <>
Subject: Re: [PATCH v4] i8k: Autodetect maximal fan speed and fan RPM multiplier

On 12/21/2014 09:23 AM, Pali Rohár wrote:
> This patch adds new function i8k_get_fan_nominal_speed() for doing SMM call
> which will return nominal fan RPM for specified fan speed. It returns nominal
> RPM value at which fan operate when speed (0, 1, 2, 3) is set. It looks like
> RPM value is not accurate, but still provides very useful information.
> First it can be used to validate if certain fan speed could be accepted by SMM
> for setting fan speed and we can use this routine to detect maximal fan speed.
> Second it returns RPM value, so we can check if value looks correct with
> multiplier 30 or multiplier 1 (until now only these two multiplier were used).
> If RPM value with multiplier 30 is too high, then multiplier 1 is used.
> In case when SMM reports that new function is not supported we will fallback
> to old hardcoded values. Maximal fan speed would be 2 and RPM multiplier 30.
> Signed-off-by: Pali Rohár <>
> Tested-by: Pali Rohár <>

Auto-detection of both multiplier and maximum speed tested working on M140
(after removing its configuration entry).

On Studio 1555, multiplier auto-detection works, but fan_max auto-detection fails.
A speed value of '3' is accepted, but it does not set the fan speed to its maximum.
Also, after setting the speed value to '3', reading it back returns to old value.
No idea what it does or is expected to do. Reading the nominal speed
does return a valid value.

Given that, I think we should not try to auto-detect fan_max, but keep the current
code (meaning either use 2 or 3 depending on the configuration data, with 2 as default
if nothing else is known).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists