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