linux-stable.git/drivers/thermal/intel, branch v5.16.4

thermal/drivers/int340x: Fix RFIM mailbox write commands

2022-01-27T11:01:23+00:00

commit 2685c77b80a80c57e2a25a726b82fb31e6e212ab upstream.

The existing mail mechanism only supports writing of workload types.

However, mailbox command for RFIM (cmd = 0x08) also requires write
operation which is ignored. This results in failing to store RFI
restriction.

Fixint this requires enhancing mailbox writes for non workload
commands too, so remove the check for MBOX_CMD_WORKLOAD_TYPE_WRITE
in mailbox write to allow this other write commands to be supoorted.

At the same time, however, we have to make sure that there is no
impact on read commands, by avoiding to write anything into the
mailbox data register.

To properly implement that, add two separate functions for mbox read
and write commands for the processor thermal workload command type.
This helps to distinguish the read and write workload command types
from each other while sending mbox commands.

Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes")
Signed-off-by: Sumeet Pawnikar 
Cc: 5.14+  # 5.14+
Acked-by: Srinivas Pandruvada 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

thermal: int340x: Fix VCoRefLow MMIO bit offset for TGL

2021-12-08T14:29:22+00:00

The VCoRefLow CPU FIVR register definition for Tiger Lake is incorrect.

Current implementation reads it from MMIO offset 0x5A18 and bit
offset [12:14], but the actual correct register definition is from
bit offset [11:13].

Update to fix the bit offset.

Fixes: 473be51142ad ("thermal: int340x: processor_thermal: Add RFIM driver")
Signed-off-by: Sumeet Pawnikar 
Cc: 5.14+  # 5.14+
[ rjw: New subject, changelog edits ]
Signed-off-by: Rafael J. Wysocki

thermal: int340x: Limit Kconfig to 64-bit

2021-11-16T19:16:35+00:00

32-bit processors cannot generally access 64-bit MMIO registers
atomically, and it is unknown in which order the two halves of
this registers would need to be read:

drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c: In function 'send_mbox_cmd':
drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c:79:37: error: implicit declaration of function 'readq'; did you mean 'readl'? [-Werror=implicit-function-declaration]
   79 |                         *cmd_resp = readq((void __iomem *) (proc_priv->mmio_base + MBOX_OFFSET_DATA));
      |                                     ^~~~~
      |                                     readl

The driver already does not build for anything other than x86,
so limit it further to x86-64.

Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Srinivas Pandruvada 
Reviewed-by: Randy Dunlap 
Signed-off-by: Rafael J. Wysocki

thermal: int340x: fix build on 32-bit targets

2021-11-12T18:56:25+00:00

Commit aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot
64 bit RFIM responses") started using 'readq()' to read 64-bit status
responses from the int340x hardware.

That's all fine and good, but on 32-bit targets a 64-bit 'readq()' is
ambiguous, since it's no longer an atomic access.  Some hardware might
require 64-bit accesses, and other hardware might want low word first or
high word first.

It's quite likely that the driver isn't relevant in a 32-bit environment
any more, and there's a patch floating around to just make it depend on
X86_64, but let's make it buildable on x86-32 anyway.

The driver previously just read the low 32 bits, so the hardware
certainly is ok with 32-bit reads, and in a little-endian environment
the low word first model is the natural one.

So just add the include for the 'io-64-nonatomic-lo-hi.h' version.

Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses")
Reported-by: Jakub Kicinski 
Cc: Srinivas Pandruvada 
Cc: Rafael J. Wysocki 
Signed-off-by: Linus Torvalds

thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses

2021-11-04T18:56:52+00:00

Some of the RFIM mail box command returns 64 bit values. So enhance
mailbox interface to return 64 bit values and use them for RFIM
commands.

Signed-off-by: Srinivas Pandruvada 
Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes")
Signed-off-by: Rafael J. Wysocki

Merge branches 'thermal-int340x', 'thermal-powerclamp' and 'thermal-docs'

2021-10-26T13:00:55+00:00

Merge Intel thermal driver updates and a thermal documentation update
for v5.16.

* thermal-int340x:
  thermal: int340x: delete bogus length check

* thermal-powerclamp:
  thermal: intel_powerclamp: Use bitmap_zalloc/bitmap_free when applicable

* thermal-docs:
  thermal: Move ABI documentation to Documentation/ABI

thermal/drivers/int340x: Improve the tcc offset saving for suspend/resume

2021-10-21T09:46:24+00:00

When the driver resumes, the tcc offset is set back to its previous
value. But this only works if the value was user defined as otherwise
the offset isn't saved. This asymmetric logic is harder to maintain and
introduced some issues.

Improve the logic by saving the tcc offset in a suspend op, so the right
value is always restored after a resume.

Signed-off-by: Antoine Tenart 
Reviewed-by: Srinivas Pandruvada 
Tested-by: Srinivas Pandruvada 
Link: https://lore.kernel.org/r/20210909085613.5577-3-atenart@kernel.org
Signed-off-by: Daniel Lezcano

thermal: int340x: delete bogus length check

2021-10-05T14:46:27+00:00

This check has a signedness bug and does not work.  If "length" is
larger than "PAGE_SIZE" then "PAGE_SIZE - length" is not negative
but instead it is a large unsigned value.  Fortunately, Takashi Iwai
changed this code to use scnprint() instead of snprintf() so now
"length" is never larger than "PAGE_SIZE - 1" and the check can be
removed.

Signed-off-by: Dan Carpenter 
Signed-off-by: Rafael J. Wysocki

thermal: intel_powerclamp: Use bitmap_zalloc/bitmap_free when applicable

2021-10-05T14:40:22+00:00

'cpu_clamping_mask' is a bitmap. So use 'bitmap_zalloc()' and
'bitmap_free()' to simplify code, improve the semantic of the code and
avoid some open-coded arithmetic in allocator arguments.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Rafael J. Wysocki

thermal/drivers/int340x: Do not set a wrong tcc offset on resume

2021-09-14T17:53:24+00:00

After upgrading to Linux 5.13.3 I noticed my laptop would shutdown due
to overheat (when it should not). It turned out this was due to commit
fe6a6de6692e ("thermal/drivers/int340x/processor_thermal: Fix tcc setting").

What happens is this drivers uses a global variable to keep track of the
tcc offset (tcc_offset_save) and uses it on resume. The issue is this
variable is initialized to 0, but is only set in
tcc_offset_degree_celsius_store, i.e. when the tcc offset is explicitly
set by userspace. If that does not happen, the resume path will set the
offset to 0 (in my case the h/w default being 3, the offset would become
too low after a suspend/resume cycle).

The issue did not arise before commit fe6a6de6692e, as the function
setting the offset would return if the offset was 0. This is no longer
the case (rightfully).

Fix this by not applying the offset if it wasn't saved before, reverting
back to the old logic. A better approach will come later, but this will
be easier to apply to stable kernels.

The logic to restore the offset after a resume was there long before
commit fe6a6de6692e, but as a value of 0 was considered invalid I'm
referencing the commit that made the issue possible in the Fixes tag
instead.

Fixes: fe6a6de6692e ("thermal/drivers/int340x/processor_thermal: Fix tcc setting")
Cc: stable@vger.kernel.org
Cc: Srinivas Pandruvada 
Signed-off-by: Antoine Tenart 
Signed-off-by: Daniel Lezcano 
Reviewed-by: Srinivas Pandruvada 
Tested-by: Srinivas Pandruvada 
Link: https://lore.kernel.org/r/20210909085613.5577-2-atenart@kernel.org