Re: [PATCH v3 3/4] thermal/core: Build ascending ordered indexes for the trip points

From: Daniel Lezcano
Date: Thu Jul 21 2022 - 05:34:46 EST


On 19/07/2022 16:17, Zhang Rui wrote:
On Tue, 2022-07-19 at 09:22 +0200, Daniel Lezcano wrote:
On 19/07/2022 03:14, Zhang Rui wrote:
On Mon, 2022-07-18 at 15:21 +0200, Daniel Lezcano wrote:

Hi Zhang,

thanks for the review

On 18/07/2022 07:28, Zhang Rui wrote:
On Fri, 2022-07-15 at 23:09 +0200, Daniel Lezcano wrote:

[ ... ]

Instead of taking the risk of breaking the existing
platforms,
use an
array of temperature ordered trip identifiers and make it
available
for the code needing to browse the trip points in an ordered
way.

Signed-off-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>
---

[ ... ]

+static void sort_trips_indexes(struct thermal_zone_device
*tz)
+{
+       int i, j;
+
+       for (i = 0; i < tz->trips; i++)
+               tz->trips_indexes[i] = i;
+
+       for (i = 0; i < tz->trips; i++) {
+               for (j = i + 1; j < tz->trips; j++) {
+                       int t1, t2;
+
+                       tz->ops->get_trip_temp(tz, tz-
trips_indexes[i], &t1);

This line can be moved to the upper loop.

Right, thanks!

+                       tz->ops->get_trip_temp(tz, tz-
trips_indexes[j], &t2);
+

what about the disabled trip points?

we should ignore those trip points and check the return value
to
make
sure we're comparing the valid trip_temp values.

We don't have to care about, whatever the position, the
corresponding
trip id will be disabled by the trip init function before calling
this
one and ignored in the handle_thermal_trip() function

hah, I missed this one and replied to your latest reply directly.

The thing I'm concerning is that if we don't check the return
value,
for a disabled trip point, the trip_temp (t1/t2) returned is some
random value, it all depends on the previous value set by last
successful .get_trip_temp(), and this may screw up the sorting.

The indexes array is the same size as the trip array, that makes the
code much less prone to errors.

To have the same number of trip points, the index of the disabled
trip
must be inserted also in the array. We don't care about its position
in
the indexes array because it is discarded in the handle_trip_point()
function anyway. For this reason, the random temperature of the
disabled
trip point and the resulting position in the sorting is harmless.

It is made on purpose to ignore the return value, so we have a
simpler code.

Let's take below case for example,
say, we have three trip points 0, 1, 2, and trip point 1 is broken and
disabled.

trip temp for trip point 0 is 10 and for trip point 2 is 20.
.get_trip_temp(tz, 1, &t) fails, and t is an uninitialized random value


Initial:
trip_indexes[0]=0,trip_indexes[1]=1,trip_indexes[2]=2
step1:
i=0,j=1
get trip temp for trip point trip_indexes[0]=0 and trip_indexes[1]=1
trip point 1 returns trip temp 5, and it swaps with trip point 0
so
trip_indexes[0]=1,trip_indexes[1]=0,trip_indexes[2]=2
step2:
i=0,j=2
get trip temp for trip point trip_indexes[0]=1 and trip_indexes[2]=2
trip point 1 returns trip temp 25, and it swaps with trip point 2
so
trip_indexes[0]=2,trip_indexes[1]=0,trip_indexes[2]=1

And the sorting is broken now.

please correct me if I'm missing anything.

Oh, nice! Thanks for the detailed explanation.

We can initialize t1 and t2 to INT_MAX, so if the get_trip_temp() fails, they will be set to the maximum temperature and it will be at the end of the array.

Alternatively, we check the disabled bit and set the temperature to INT_MAX.





--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog