mbox series

[v1,0/8] thermal: intel: intel_pch: Code simplification and cleanups

Message ID 1751684.VLH7GnMWUR@kreacher
Headers
Series thermal: intel: intel_pch: Code simplification and cleanups |

Message

Rafael J. Wysocki Jan. 30, 2023, 6:56 p.m. UTC 
  Hi All,

This patch series removes some uneeded code and data structures from the
intel_pch_thermal driver, rearranges it and does some assorted minor cleanups
(no change in behavior should result from it).

Please refer to the individual patch changelogs for details.

Thanks!

Comments

Rafael J. Wysocki Jan. 30, 2023, 7:13 p.m. UTC | #1 
On Mon, Jan 30, 2023 at 8:08 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> Hi All,
>
> This patch series removes some uneeded code and data structures from the
> intel_pch_thermal driver, rearranges it and does some assorted minor cleanups
> (no change in behavior should result from it).
>
> Please refer to the individual patch changelogs for details.

I forgot to mention that this series is applicable on top of

https://patchwork.kernel.org/project/linux-pm/patch/5641279.DvuYhMxLoT@kreacher/

which in turn applies on top of the current thermal branch in linux-pm.git,
that is also present in the linux-next branch in linux-pm.git.

Thanks!
Zhang, Rui Feb. 1, 2023, 9:06 a.m. UTC | #2 
On Mon, 2023-01-30 at 19:56 +0100, Rafael J. Wysocki wrote:
> Hi All,
> 
> This patch series removes some uneeded code and data structures from
> the
> intel_pch_thermal driver, rearranges it and does some assorted minor
> cleanups
> (no change in behavior should result from it).
> 
> Please refer to the individual patch changelogs for details.
> 
> Thanks!
> 
Tested on one KBL-R platform, everything works fine.

Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>

thanks,
rui
Zhang, Rui Feb. 1, 2023, 9:08 a.m. UTC | #3 
On Wed, 2023-02-01 at 17:06 +0800, Zhang Rui wrote:
> On Mon, 2023-01-30 at 19:56 +0100, Rafael J. Wysocki wrote:
> > Hi All,
> > 
> > This patch series removes some uneeded code and data structures
> > from
> > the
> > intel_pch_thermal driver, rearranges it and does some assorted
> > minor
> > cleanups
> > (no change in behavior should result from it).
> > 
> > Please refer to the individual patch changelogs for details.
> > 
> > Thanks!
> > 
> Tested on one KBL-R platform, everything works fine.
> 
> Tested-by: Zhang Rui <rui.zhang@intel.com>
> Reviewed-by: Zhang Rui <rui.zhang@intel.com>

Forgot to mention, I tested patch 1~7 in this series, plus the appended
patch in patch 7/8 thread.

> 
> thanks,
> rui
Zhang, Rui Feb. 1, 2023, 9:30 a.m. UTC | #4 
On Mon, 2023-01-30 at 20:13 +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 30, 2023 at 8:08 PM Rafael J. Wysocki <rjw@rjwysocki.net>
> wrote:
> > Hi All,
> > 
> > This patch series removes some uneeded code and data structures
> > from the
> > intel_pch_thermal driver, rearranges it and does some assorted
> > minor cleanups
> > (no change in behavior should result from it).
> > 
> > Please refer to the individual patch changelogs for details.
> 
> I forgot to mention that this series is applicable on top of
> 
> https://patchwork.kernel.org/project/linux-pm/patch/5641279.DvuYhMxLoT@kreacher/
> 
> which in turn applies on top of the current thermal branch in linux-
> pm.git,
> that is also present in the linux-next branch in linux-pm.git.
> 
I also tested your linux-next branch but without the "thermal" merge.

-/sys/class/thermal/thermal_zone7/trip_point_4_temp:-32768000
+/sys/class/thermal/thermal_zone7/trip_point_4_hyst:0
+/sys/class/thermal/thermal_zone7/trip_point_4_temp:-2147483648

The new "hyst" attribute is not a problem as it is mandatory for
generic trips.

The temp value changes is introduced by commit
3d2f20ad46f8 ("wifi: iwlwifi: Use generic thermal_zone_get_trip()
function")

-       for (i = 0 ; i < IWL_MAX_DTS_TRIPS; i++)
-               mvm->tz_device.temp_trips[i] = S16_MIN;
+       for (i = 0 ; i < IWL_MAX_DTS_TRIPS; i++) {
+               mvm->tz_device.trips[i].temperature = INT_MIN;
+               mvm->tz_device.trips[i].type = THERMAL_TRIP_PASSIVE;
+       }

It is kind of strange to use different values, but both represents a
bogus temperature. What about using THERMAL_TEMP_INVALID for future
consistency?

thanks,
rui