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.1361206053.493518.2246.1000@galar>
Date:	Mon, 18 Feb 2013 17:47:33 +0100
From:	Peter Feuerer <peter@...e.net>
To:	Borislav Petkov <bp@...en8.de>,
	Zhang, Rui <rui.zhang@...el.com>
Cc:	Alexander Lam <azl@...rew.cmu.edu>,
	linux-kernel@...r.kernel.org 
	<linux-kernel@...r.kernel.org>, Andreas Mohr <andi@...as.de>
Subject: Re: thermal governor: does it actually work??

Hi Boris, Hi Rui,

@Rui, would be great, if you could review the patch and verify, whether
everything I'm telling is the truth, thanks.


Borislav Petkov writes:

> On Sun, Feb 17, 2013 at 04:41:57PM +0100, Peter Feuerer wrote:
>> Don't think so, I think this was already in since 2.6.<something> and
>> I assume with this patch applied, acerhdf works from at least this
>> 2.6.<something> up to new 3.8 and will still work in the future.
> 
> Well, it can't be because there wouldn't be breakage otherwise, right?
> I've been running 3.5 on the atom for a long time and it was ok but 3.8
> is showing the issue. So something *has* changed.

I think previous 3.7 were two methods possible, the method with one trippoint,
on which the state gets switched on and off using this code in thermal_sys.c:
1060                                if (temp >= trip_temp)
1061                                        cdev->ops->set_cur_state(cdev, 1);
1062                                else
1063                                        cdev->ops->set_cur_state(cdev, 0);


And the other method with all the different trip points, which is used after 
applying my patch.
The older way has been removed intentionally or not, I don't know. But as
acerhdf was depending on this old way, it stopped working.


> But, as you say above, I guess the two-point scheme of acerhdf doesn't
> have a governor that fits. So maybe the correct solution is to have an
> "on_off" stupid governor which gets used by acerhdf and does simply call
> into acerhdf to switch on the fan to auto above a specified trip point.
> 
> It could be a lot of overhead for nothing in the end, though.

I think adding a two-point governor would maybe be the somehow cleaner way...
Rui, what do you think, is there a way, you could provide a two-point governor
with upper temperature for turning on the fan and a lower temperature for
turning it off again?


>> >Maybe the critical and hot types need to go here? I.e., 3 and 4?
>> 
>> Yes, crit has to go there.
> 
> Right, I'll wait for that version of the patch to test. :)

I added crit to the patch below.



>From 74af34f3099828d5c7c2b4fd4ccf445edfdc6f1e Mon Sep 17 00:00:00 2001
From: Peter Feuerer <peter@...e.net>
Date: Mon, 18 Feb 2013 17:23:34 +0100
Subject: [PATCH] added three more trip points to acerhdf, this allows thermal
 layer to correctly handle the two point regulation of acerhdf. Trip point 0
 will be active from 0 degree to "fanoff" and is marked as passive, then trip
 point 1 is valid from "fanoff" to "fanon" value and is marked as active, even
 if it's only really active in case temperature is going down from trip point
 2. Trip point 2 will be valid above "fanon" value and is also marked as
 active. Trip point 3 is when hitting the critical temperature.

---
 drivers/platform/x86/acerhdf.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f94467c..b121449 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -400,7 +400,13 @@ static int acerhdf_get_trip_type(struct thermal_zone_device *thermal, int trip,
 				 enum thermal_trip_type *type)
 {
 	if (trip == 0)
+		*type = THERMAL_TRIP_PASSIVE;
+	if (trip == 1)
 		*type = THERMAL_TRIP_ACTIVE;
+	if (trip == 2)
+		*type = THERMAL_TRIP_ACTIVE;
+	if (trip == 3)
+		*type = THERMAL_TRIP_CRITICAL;
 
 	return 0;
 }
@@ -409,7 +415,13 @@ static int acerhdf_get_trip_temp(struct thermal_zone_device *thermal, int trip,
 				 unsigned long *temp)
 {
 	if (trip == 0)
+		*temp = 0;
+	if (trip == 1)
+		*temp = fanoff;
+	if (trip == 2)
 		*temp = fanon;
+	if (trip == 3)
+		*temp = ACERHDF_TEMP_CRIT;
 
 	return 0;
 }
@@ -431,6 +443,7 @@ static struct thermal_zone_device_ops acerhdf_dev_ops = {
 	.get_trip_type = acerhdf_get_trip_type,
 	.get_trip_temp = acerhdf_get_trip_temp,
 	.get_crit_temp = acerhdf_get_crit_temp,
+	.notify = NULL,
 };
 
 
@@ -486,7 +499,8 @@ static int acerhdf_set_cur_state(struct thermal_cooling_device *cdev,
 		    (cur_temp < fanoff))
 			acerhdf_change_fanstate(ACERHDF_FAN_OFF);
 	} else {
-		if (cur_state == ACERHDF_FAN_OFF)
+		if ((cur_state == ACERHDF_FAN_OFF) &&
+		    (cur_temp > fanon))
 			acerhdf_change_fanstate(ACERHDF_FAN_AUTO);
 	}
 	return 0;
@@ -661,8 +675,9 @@ static int acerhdf_register_thermal(void)
 	if (IS_ERR(cl_dev))
 		return -EINVAL;
 
-	thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
-					      &acerhdf_dev_ops, NULL, 0,
+	thz_dev = thermal_zone_device_register("acerhdf", 4, 0, NULL,
+					      &acerhdf_dev_ops,
+					      (kernelmode) ? interval*1000 : 0,
 					      (kernelmode) ? interval*1000 : 0);
 	if (IS_ERR(thz_dev))
 		return -EINVAL;
-- 
1.8.1.3

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ