linux-stable.git/drivers/thermal/intel, branch v6.4.2

thermal/intel/intel_soc_dts_iosf: Fix reporting wrong temperatures

2023-06-15T16:07:48+00:00

Since commit 955fb8719efb ("thermal/intel/intel_soc_dts_iosf: Use Intel
TCC library") intel_soc_dts_iosf is reporting the wrong temperature.

The driver expects tj_max to be in milli-degrees-celcius but after
the switch to the TCC library this is now in degrees celcius so
instead of e.g. 90000 it is set to 90 causing a temperature 45
degrees below tj_max to be reported as -44910 milli-degrees
instead of as 45000 milli-degrees.

Fix this by adding back the lost factor of 1000.

Fixes: 955fb8719efb ("thermal/intel/intel_soc_dts_iosf: Use Intel TCC library")
Reported-by: Bernhard Krug 
Signed-off-by: Hans de Goede 
Acked-by: Zhang Rui 
Cc: 6.3+  # 6.3+
Signed-off-by: Rafael J. Wysocki

thermal: intel: int340x: Add new line for UUID display

2023-05-24T17:50:04+00:00

Prior to the commit "763bd29fd3d1 ("thermal: int340x_thermal: Use
sysfs_emit_at() instead of scnprintf()", there was a new line after each
UUID string.

With the newline removed, existing user space like "thermald" fails to
compare each supported UUID as it is using getline() to read UUID and
apply correct thermal table.

To avoid breaking existing user space, add newline after each UUID string.

Signed-off-by: Srinivas Pandruvada 
Fixes: 763bd29fd3d1 ("thermal: int340x_thermal: Use sysfs_emit_at() instead of scnprintf()")
Cc: 6.3+  # 6.3+
Signed-off-by: Rafael J. Wysocki

thermal: intel: powerclamp: Fix NULL pointer access issue

2023-05-04T18:30:18+00:00

If cur_state for the powerclamp cooling device is set to the default
minimum state of 0, without setting first to cur_state > 0, this results
in NULL pointer access.

This NULL pointer access happens in the powercap core idle-inject
function idle_inject_set_duration() as there is no NULL check for
idle_inject_device pointer. This pointer must be allocated by calling
idle_inject_register() or idle_inject_register_full().

In the function powerclamp_set_cur_state(), idle_inject_device pointer
is allocated only when the cur_state > 0. But setting 0 without changing
to any other state, idle_inject_set_duration() will be called with a
NULL idle_inject_device pointer.

To address this, just return from powerclamp_set_cur_state() if the
current cooling device state is the same as the last one. Since the
power-up default cooling device state is 0, changing the state to 0
again here will return without calling idle_inject_set_duration().

Signed-off-by: Srinivas Pandruvada 
Fixes: 8526eb7fc75a ("thermal: intel: powerclamp: Use powercap idle-inject feature")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217386
Tested-by: Risto A. Paju 
Cc: 6.3+  # 6.3+
Signed-off-by: Rafael J. Wysocki

thermal: intel: menlow: Get rid of this driver

2023-04-27T17:24:13+00:00

According to my information, there are no active users of this driver in
the field.

Moreover, it does some really questionable things and gets in the way of
thermal core improvements, so drop it.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Daniel Lezcano

thermal: intel: pch_thermal: Use thermal driver device to write a trace

2023-04-27T17:20:12+00:00

The pch_critical() callback accesses the thermal zone device structure
internals, it dereferences the thermal zone struct device and the 'type'.

Use the available accessors instead of accessing the structure directly.

Signed-off-by: Daniel Lezcano 
Signed-off-by: Rafael J. Wysocki

thermal: intel: int340x: Add DLVR support for RFIM control

2023-04-18T13:24:40+00:00

Add support for DLVR (Digital Linear Voltage Regulator) attributes,
which can be used to control RFIM.

Here instead of "fivr" another directory "dlvr" is created with DLVR
attributes:

/sys/bus/pci/devices/0000:00:04.0/dlvr
├── dlvr_freq_mhz
├── dlvr_freq_select
├── dlvr_hardware_rev
├── dlvr_pll_busy
├── dlvr_rfim_enable
└── dlvr_spread_spectrum_pct
└── dlvr_control_mode
└── dlvr_control_lock

Attributes
dlvr_freq_mhz (RO):
Current DLVR PLL frequency in MHz.

dlvr_freq_select (RW):
Sets DLVR PLL clock frequency.

dlvr_hardware_rev (RO):
DLVR hardware revision.

dlvr_pll_busy (RO):
PLL can't accept frequency change when set.

dlvr_rfim_enable (RW):
0: Disable RF frequency hopping, 1: Enable RF frequency hopping.

dlvr_control_mode (RW):
Specifies how frequencies are spread. 0: Down spread, 1: Spread in Center.

dlvr_control_lock (RW):
1: future writes are ignored.

dlvr_spread_spectrum_pct (RW)
A write to this register updates the DLVR spread spectrum percent value.

Signed-off-by: Srinivas Pandruvada 
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki

Merge back Intel thermal control material for 6.4-rc1.

2023-04-14T15:14:02+00:00

thermal: intel: Avoid updating unsupported THERM_STATUS_CLEAR mask bits

2023-04-11T16:12:19+00:00

Some older processors don't allow BIT(13) and BIT(15) in the current
mask set by "THERM_STATUS_CLEAR_CORE_MASK". This results in:

unchecked MSR access error: WRMSR to 0x19c (tried to
write 0x000000000000aaa8) at rIP: 0xffffffff816f66a6
(throttle_active_work+0xa6/0x1d0)

To avoid unchecked MSR issues, check CPUID for each relevant feature and
use that information to set the supported feature bits only in the
"clear" mask for cores. Do the same for the analogous package mask set
by "THERM_STATUS_CLEAR_PKG_MASK".

Introduce functions thermal_intr_init_core_clear_mask() and
thermal_intr_init_pkg_clear_mask() to set core and package mask bits,
respectively. These functions are called during initialization.

Fixes: 6fe1e64b6026 ("thermal: intel: Prevent accidental clearing of HFI status")
Reported-by: Rui Salvaterra 
Link: https://lore.kernel.org/lkml/cdf43fb423368ee3994124a9e8c9b4f8d00712c6.camel@linux.intel.com/T/
Tested-by: Rui Salvaterra 
Signed-off-by: Srinivas Pandruvada 
Cc: 6.2+  # 6.2+
[ rjw: Renamed 2 funtions and 2 static variables, edited subject and
  changelog ]
Signed-off-by: Rafael J. Wysocki

Merge back Intel thermal driver changes for 6.4-rc1.

2023-03-31T17:32:43+00:00

thermal: intel: powerclamp: Fix cpumask and max_idle module parameters

2023-03-30T18:04:29+00:00

When cpumask is specified as a module parameter the value is
overwritten by the module init routine.  This can easily be fixed
by checking to see if the mask has already been allocated in the
init routine.

When max_idle is specified as a module parameter a panic will occur.
The problem is that the idle_injection_cpu_mask is not allocated until
the module init routine executes. This can easily be fixed by allocating
the cpumask if it's not already allocated.

Fixes: ebf519710218 ("thermal: intel: powerclamp: Add two module parameters")
Signed-off-by: David Arcari 
Reviewed-by: Srinivas Pandruvada
Signed-off-by: Rafael J. Wysocki