Hello,
This is my first time requesting inclusion of a patch, please
point out any breach of protocol.
I'm using linux-3.14.y and I've run into a bug fixed in later
kernel versions:
commit 26bb0e9a1a938ec98ee07aa76533f1a711fba706
Author: Lukasz Majewski <[email protected]>
Date: Wed Sep 24 10:27:10 2014 +0200
thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
It turns out that some boards can have instance->lower greater than 0 and
when thermal trend is dropping it results with next_target equal to -1.
Since the next_target is defined as unsigned long it is interpreted as
0xFFFFFFFF and larger than instance->upper.
As a result the next_target is set to instance->upper which ramps up to
maximal cooling device target when the temperature is steadily decreasing.
Signed-off-by: Lukasz Majewski <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index f251521baaa2..6705a0d746b3 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -76,7 +76,7 @@ static unsigned long get_target_state(struct thermal_instance *instance,
next_target = instance->upper;
break;
case THERMAL_TREND_DROPPING:
- if (cur_state == instance->lower) {
+ if (cur_state <= instance->lower) {
if (!throttle)
next_target = THERMAL_NO_TARGET;
} else {
Here's the debug output on my board:
[ 21.301211] thermal thermal_zone0: last_temperature=0, current_temperature=51000
[ 21.308803] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=1,throttle=0
[ 21.316248] thermal cooling_device0: cur_state=0
[ 21.320957] thermal cooling_device0: old_target=-1, target=-1
[ 21.326755] thermal cooling_device0: zone0->target=4294967295
[ 21.332544] thermal cooling_device0: set to state 0
[ 34.349747] thermal thermal_zone0: last_temperature=51000, current_temperature=46000
[ 34.357830] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=2,throttle=0
[ 34.365254] thermal cooling_device0: cur_state=0
[ 34.369989] thermal cooling_device0: old_target=-1, target=4
[ 34.375740] thermal cooling_device0: zone0->target=4
[ 34.380867] thermal cooling_device0: set to state 4
Bug: raising the cooling state, despite the temperature dropping.
The .bind() call was
thermal_zone_bind_cooling_device(tz, 0, cdev, 4, 1);
(The intent being that, once the system is above the trip temp,
at least a little bit of cooling should be applied, always.)
cur_state = 0 is not equal to lower_state = 1
AFAICT, Lukasz's patch fixes that issue.
Regards.
On Tue, Jul 21, 2015 at 01:41:09PM +0200, Mason wrote:
> Hello,
>
> This is my first time requesting inclusion of a patch, please
> point out any breach of protocol.
>
> I'm using linux-3.14.y and I've run into a bug fixed in later
> kernel versions:
>
> commit 26bb0e9a1a938ec98ee07aa76533f1a711fba706
> Author: Lukasz Majewski <[email protected]>
> Date: Wed Sep 24 10:27:10 2014 +0200
>
> thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
>
> It turns out that some boards can have instance->lower greater than 0 and
> when thermal trend is dropping it results with next_target equal to -1.
>
> Since the next_target is defined as unsigned long it is interpreted as
> 0xFFFFFFFF and larger than instance->upper.
> As a result the next_target is set to instance->upper which ramps up to
> maximal cooling device target when the temperature is steadily decreasing.
>
> Signed-off-by: Lukasz Majewski <[email protected]>
> Signed-off-by: Zhang Rui <[email protected]>
>
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index f251521baaa2..6705a0d746b3 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -76,7 +76,7 @@ static unsigned long get_target_state(struct thermal_instance *instance,
> next_target = instance->upper;
> break;
> case THERMAL_TREND_DROPPING:
> - if (cur_state == instance->lower) {
> + if (cur_state <= instance->lower) {
> if (!throttle)
> next_target = THERMAL_NO_TARGET;
> } else {
>
>
>
>
> Here's the debug output on my board:
>
> [ 21.301211] thermal thermal_zone0: last_temperature=0, current_temperature=51000
> [ 21.308803] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=1,throttle=0
> [ 21.316248] thermal cooling_device0: cur_state=0
> [ 21.320957] thermal cooling_device0: old_target=-1, target=-1
> [ 21.326755] thermal cooling_device0: zone0->target=4294967295
> [ 21.332544] thermal cooling_device0: set to state 0
>
> [ 34.349747] thermal thermal_zone0: last_temperature=51000, current_temperature=46000
> [ 34.357830] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=2,throttle=0
> [ 34.365254] thermal cooling_device0: cur_state=0
> [ 34.369989] thermal cooling_device0: old_target=-1, target=4
> [ 34.375740] thermal cooling_device0: zone0->target=4
> [ 34.380867] thermal cooling_device0: set to state 4
>
> Bug: raising the cooling state, despite the temperature dropping.
>
> The .bind() call was
>
> thermal_zone_bind_cooling_device(tz, 0, cdev, 4, 1);
>
> (The intent being that, once the system is above the trip temp,
> at least a little bit of cooling should be applied, always.)
>
> cur_state = 0 is not equal to lower_state = 1
>
> AFAICT, Lukasz's patch fixes that issue.
Now queued up, thanks.
greg k-h
On Tue, Jul 21, 2015 at 01:41:09PM +0200, Mason wrote:
> Hello,
>
> This is my first time requesting inclusion of a patch, please
> point out any breach of protocol.
>
> I'm using linux-3.14.y and I've run into a bug fixed in later
> kernel versions:
>
Thanks, I'm queuing this patch for the 3.16 kernel as well.
Cheers,
--
Lu?s
> commit 26bb0e9a1a938ec98ee07aa76533f1a711fba706
> Author: Lukasz Majewski <[email protected]>
> Date: Wed Sep 24 10:27:10 2014 +0200
>
> thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
>
> It turns out that some boards can have instance->lower greater than 0 and
> when thermal trend is dropping it results with next_target equal to -1.
>
> Since the next_target is defined as unsigned long it is interpreted as
> 0xFFFFFFFF and larger than instance->upper.
> As a result the next_target is set to instance->upper which ramps up to
> maximal cooling device target when the temperature is steadily decreasing.
>
> Signed-off-by: Lukasz Majewski <[email protected]>
> Signed-off-by: Zhang Rui <[email protected]>
>
> diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
> index f251521baaa2..6705a0d746b3 100644
> --- a/drivers/thermal/step_wise.c
> +++ b/drivers/thermal/step_wise.c
> @@ -76,7 +76,7 @@ static unsigned long get_target_state(struct thermal_instance *instance,
> next_target = instance->upper;
> break;
> case THERMAL_TREND_DROPPING:
> - if (cur_state == instance->lower) {
> + if (cur_state <= instance->lower) {
> if (!throttle)
> next_target = THERMAL_NO_TARGET;
> } else {
>
>
>
>
> Here's the debug output on my board:
>
> [ 21.301211] thermal thermal_zone0: last_temperature=0, current_temperature=51000
> [ 21.308803] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=1,throttle=0
> [ 21.316248] thermal cooling_device0: cur_state=0
> [ 21.320957] thermal cooling_device0: old_target=-1, target=-1
> [ 21.326755] thermal cooling_device0: zone0->target=4294967295
> [ 21.332544] thermal cooling_device0: set to state 0
>
> [ 34.349747] thermal thermal_zone0: last_temperature=51000, current_temperature=46000
> [ 34.357830] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=2,throttle=0
> [ 34.365254] thermal cooling_device0: cur_state=0
> [ 34.369989] thermal cooling_device0: old_target=-1, target=4
> [ 34.375740] thermal cooling_device0: zone0->target=4
> [ 34.380867] thermal cooling_device0: set to state 4
>
> Bug: raising the cooling state, despite the temperature dropping.
>
> The .bind() call was
>
> thermal_zone_bind_cooling_device(tz, 0, cdev, 4, 1);
>
> (The intent being that, once the system is above the trip temp,
> at least a little bit of cooling should be applied, always.)
>
> cur_state = 0 is not equal to lower_state = 1
>
> AFAICT, Lukasz's patch fixes that issue.
>
> Regards.
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html