Skip to contentSkip to conversation

Requesting inclusion of 26bb0e9a in linux-3.14.y

PATCH Mason 3 participants 3 messages Jul 21, 2015 – Jul 27, 2015

Subsystems (2)
lore
Share & tools
lore

Mason

author
#0 lore raw

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.

drivers/thermal/step_wise.c +1 -1
index f251521baaa2..6705a0d746b3 100644
@@ -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.

maintainer
#1 lore raw
Quoted 62 lines · Mason

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.

drivers/thermal/step_wise.c +1 -1
index f251521baaa2..6705a0d746b3 100644
@@ -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

Quoted 8 lines
  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

#2 lore raw
In reply to Mason
Quoted 8 lines · Mason

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

Quoted 68 lines

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.

drivers/thermal/step_wise.c +1 -1
index f251521baaa2..6705a0d746b3 100644
@@ -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