<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/thermal/intel, branch linux-5.16.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2022-04-08T12:05:37+00:00</updated>
<entry>
<title>thermal: int340x: Check for NULL after calling kmemdup()</title>
<updated>2022-04-08T12:05:37+00:00</updated>
<author>
<name>Jiasheng Jiang</name>
<email>jiasheng@iscas.ac.cn</email>
</author>
<published>2022-01-26T01:48:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f506aeed0fe4b499caad68f746342925c3a3aedc'/>
<id>urn:sha1:f506aeed0fe4b499caad68f746342925c3a3aedc</id>
<content type='text'>
[ Upstream commit 38b16d6cfe54c820848bcfc999bc5e8a7da1cefb ]

As the potential failure of the allocation, kmemdup() may return NULL.

Then, 'bin_attr_data_vault.private' will be NULL, but
'bin_attr_data_vault.size' is not 0, which is not consistent.

Therefore, it is better to check the return value of kmemdup() to
avoid the confusion.

Fixes: 0ba13c763aac ("thermal/int340x_thermal: Export GDDV")
Signed-off-by: Jiasheng Jiang &lt;jiasheng@iscas.ac.cn&gt;
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>thermal: int340x: Increase bitmap size</title>
<updated>2022-04-08T12:05:32+00:00</updated>
<author>
<name>Srinivas Pandruvada</name>
<email>srinivas.pandruvada@linux.intel.com</email>
</author>
<published>2022-03-14T22:08:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=27a439baeb44468eec76cf50585967202ba16757'/>
<id>urn:sha1:27a439baeb44468eec76cf50585967202ba16757</id>
<content type='text'>
commit 668f69a5f863b877bc3ae129efe9a80b6f055141 upstream.

The number of policies are 10, so can't be supported by the bitmap size
of u8.

Even though there are no platfoms with these many policies, but
for correctness increase to u32.

Signed-off-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Fixes: 16fc8eca1975 ("thermal/int340x_thermal: Add additional UUIDs")
Cc: 5.1+ &lt;stable@vger.kernel.org&gt; # 5.1+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thermal: int340x: fix memory leak in int3400_notify()</title>
<updated>2022-03-02T10:51:18+00:00</updated>
<author>
<name>Chuansheng Liu</name>
<email>chuansheng.liu@intel.com</email>
</author>
<published>2022-02-23T00:20:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=33c73a4d7e7b19313a6b417152f5365016926418'/>
<id>urn:sha1:33c73a4d7e7b19313a6b417152f5365016926418</id>
<content type='text'>
commit 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 upstream.

It is easy to hit the below memory leaks in my TigerLake platform:

unreferenced object 0xffff927c8b91dbc0 (size 32):
  comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
  hex dump (first 32 bytes):
    4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65  NAME=INT3400 The
    72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  rmal.kkkkkkkkkk.
  backtrace:
    [&lt;ffffffff9c502c3e&gt;] __kmalloc_track_caller+0x2fe/0x4a0
    [&lt;ffffffff9c7b7c15&gt;] kvasprintf+0x65/0xd0
    [&lt;ffffffff9c7b7d6e&gt;] kasprintf+0x4e/0x70
    [&lt;ffffffffc04cb662&gt;] int3400_notify+0x82/0x120 [int3400_thermal]
    [&lt;ffffffff9c8b7358&gt;] acpi_ev_notify_dispatch+0x54/0x71
    [&lt;ffffffff9c88f1a7&gt;] acpi_os_execute_deferred+0x17/0x30
    [&lt;ffffffff9c2c2c0a&gt;] process_one_work+0x21a/0x3f0
    [&lt;ffffffff9c2c2e2a&gt;] worker_thread+0x4a/0x3b0
    [&lt;ffffffff9c2cb4dd&gt;] kthread+0xfd/0x130
    [&lt;ffffffff9c201c1f&gt;] ret_from_fork+0x1f/0x30

Fix it by calling kfree() accordingly.

Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event")
Signed-off-by: Chuansheng Liu &lt;chuansheng.liu@intel.com&gt;
Cc: 4.14+ &lt;stable@vger.kernel.org&gt; # 4.14+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thermal/drivers/int340x: Fix RFIM mailbox write commands</title>
<updated>2022-01-27T11:01:23+00:00</updated>
<author>
<name>Sumeet Pawnikar</name>
<email>sumeet.r.pawnikar@intel.com</email>
</author>
<published>2021-12-23T09:42:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7d0a23de5f41810827891c844a6ab7653bda4028'/>
<id>urn:sha1:7d0a23de5f41810827891c844a6ab7653bda4028</id>
<content type='text'>
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 &lt;sumeet.r.pawnikar@intel.com&gt;
Cc: 5.14+ &lt;stable@vger.kernel.org&gt; # 5.14+
Acked-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>thermal: int340x: Fix VCoRefLow MMIO bit offset for TGL</title>
<updated>2021-12-08T14:29:22+00:00</updated>
<author>
<name>Sumeet Pawnikar</name>
<email>sumeet.r.pawnikar@intel.com</email>
</author>
<published>2021-12-07T12:35:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f872f73601b92c86f3da8bdf3e19abd0f1780eb9'/>
<id>urn:sha1:f872f73601b92c86f3da8bdf3e19abd0f1780eb9</id>
<content type='text'>
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 &lt;sumeet.r.pawnikar@intel.com&gt;
Cc: 5.14+ &lt;stable@vger.kernel.org&gt; # 5.14+
[ rjw: New subject, changelog edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>thermal: int340x: Limit Kconfig to 64-bit</title>
<updated>2021-11-16T19:16:35+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2021-11-08T11:13:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=994a04a20b03128838ec0250a0e266aab24d23f1'/>
<id>urn:sha1:994a04a20b03128838ec0250a0e266aab24d23f1</id>
<content type='text'>
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-&gt;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 &lt;arnd@arndb.de&gt;
Reviewed-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>thermal: int340x: fix build on 32-bit targets</title>
<updated>2021-11-12T18:56:25+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-11-12T18:56:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d9c8e52ff9e84ff1a406330f9ea4de7c5eb40282'/>
<id>urn:sha1:d9c8e52ff9e84ff1a406330f9ea4de7c5eb40282</id>
<content type='text'>
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 &lt;kuba@kernel.org&gt;
Cc: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Cc: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses</title>
<updated>2021-11-04T18:56:52+00:00</updated>
<author>
<name>Srinivas Pandruvada</name>
<email>srinivas.pandruvada@linux.intel.com</email>
</author>
<published>2021-11-02T10:52:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=aeb58c860dc516794fdf7ff89d96ead2644d5889'/>
<id>urn:sha1:aeb58c860dc516794fdf7ff89d96ead2644d5889</id>
<content type='text'>
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 &lt;srinivas.pandruvada@linux.intel.com&gt;
Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes")
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge branches 'thermal-int340x', 'thermal-powerclamp' and 'thermal-docs'</title>
<updated>2021-10-26T13:00:55+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2021-10-26T13:00:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=46e9f92f31e67385fab8b49c030635415f36b362'/>
<id>urn:sha1:46e9f92f31e67385fab8b49c030635415f36b362</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>thermal/drivers/int340x: Improve the tcc offset saving for suspend/resume</title>
<updated>2021-10-21T09:46:24+00:00</updated>
<author>
<name>Antoine Tenart</name>
<email>atenart@kernel.org</email>
</author>
<published>2021-09-09T08:56:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c4fcf1ada4ae63e0aab6afd19ca2e7d16833302c'/>
<id>urn:sha1:c4fcf1ada4ae63e0aab6afd19ca2e7d16833302c</id>
<content type='text'>
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 &lt;atenart@kernel.org&gt;
Reviewed-by: Srinivas Pandruvada &lt;srinivas.pandruvada@linux.intel.com&gt;
Tested-by: Srinivas Pandruvada &lt;srinivas.pI andruvada@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20210909085613.5577-3-atenart@kernel.org
Signed-off-by: Daniel Lezcano &lt;daniel.lezcano@linaro.org&gt;
</content>
</entry>
</feed>
