From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Mark Pearson <markpearson@lenovo.com>,
Hans de Goede <hdegoede@redhat.com>,
Sasha Levin <sashal@kernel.org>,
ibm-acpi-devel@lists.sourceforge.net,
platform-driver-x86@vger.kernel.org
Subject: [PATCH AUTOSEL 4.14 13/16] platform/x86: thinkpad_acpi: Correct thermal sensor allocation
Date: Sun, 2 May 2021 10:05:41 -0400 [thread overview]
Message-ID: <20210502140544.2720138-13-sashal@kernel.org> (raw)
In-Reply-To: <20210502140544.2720138-1-sashal@kernel.org>
From: Mark Pearson <markpearson@lenovo.com>
[ Upstream commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 ]
On recent Thinkpad platforms it was reported that temp sensor 11 was
always incorrectly displaying 66C. It turns out the reason for this is
that this location in EC RAM is not a temperature sensor but is the
power supply ID (offset 0xC2).
Based on feedback from the Lenovo firmware team the EC RAM version can
be determined and for the current version (3) only the 0x78 to 0x7F
range is used for temp sensors. I don't have any details for earlier
versions so I have left the implementation unaltered there.
Note - in this block only 0x78 and 0x79 are officially designated (CPU &
GPU sensors). The use of the other locations in the block will vary from
platform to platform; but the existing logic to detect a sensor presence
holds.
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/thinkpad_acpi.c | 31 ++++++++++++++++++++--------
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 30bfd51c0e58..30bc952ea552 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -6162,6 +6162,7 @@ enum thermal_access_mode {
enum { /* TPACPI_THERMAL_TPEC_* */
TP_EC_THERMAL_TMP0 = 0x78, /* ACPI EC regs TMP 0..7 */
TP_EC_THERMAL_TMP8 = 0xC0, /* ACPI EC regs TMP 8..15 */
+ TP_EC_FUNCREV = 0xEF, /* ACPI EC Functional revision */
TP_EC_THERMAL_TMP_NA = -128, /* ACPI EC sensor not available */
TPACPI_THERMAL_SENSOR_NA = -128000, /* Sensor not available */
@@ -6360,7 +6361,7 @@ static const struct attribute_group thermal_temp_input8_group = {
static int __init thermal_init(struct ibm_init_struct *iibm)
{
- u8 t, ta1, ta2;
+ u8 t, ta1, ta2, ver = 0;
int i;
int acpi_tmp7;
int res;
@@ -6375,7 +6376,14 @@ static int __init thermal_init(struct ibm_init_struct *iibm)
* 0x78-0x7F, 0xC0-0xC7. Registers return 0x00 for
* non-implemented, thermal sensors return 0x80 when
* not available
+ * The above rule is unfortunately flawed. This has been seen with
+ * 0xC2 (power supply ID) causing thermal control problems.
+ * The EC version can be determined by offset 0xEF and at least for
+ * version 3 the Lenovo firmware team confirmed that registers 0xC0-0xC7
+ * are not thermal registers.
*/
+ if (!acpi_ec_read(TP_EC_FUNCREV, &ver))
+ pr_warn("Thinkpad ACPI EC unable to access EC version\n");
ta1 = ta2 = 0;
for (i = 0; i < 8; i++) {
@@ -6385,11 +6393,13 @@ static int __init thermal_init(struct ibm_init_struct *iibm)
ta1 = 0;
break;
}
- if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, &t)) {
- ta2 |= t;
- } else {
- ta1 = 0;
- break;
+ if (ver < 3) {
+ if (acpi_ec_read(TP_EC_THERMAL_TMP8 + i, &t)) {
+ ta2 |= t;
+ } else {
+ ta1 = 0;
+ break;
+ }
}
}
if (ta1 == 0) {
@@ -6402,9 +6412,12 @@ static int __init thermal_init(struct ibm_init_struct *iibm)
thermal_read_mode = TPACPI_THERMAL_NONE;
}
} else {
- thermal_read_mode =
- (ta2 != 0) ?
- TPACPI_THERMAL_TPEC_16 : TPACPI_THERMAL_TPEC_8;
+ if (ver >= 3)
+ thermal_read_mode = TPACPI_THERMAL_TPEC_8;
+ else
+ thermal_read_mode =
+ (ta2 != 0) ?
+ TPACPI_THERMAL_TPEC_16 : TPACPI_THERMAL_TPEC_8;
}
} else if (acpi_tmp7) {
if (tpacpi_is_ibm() &&
--
2.30.2
next prev parent reply other threads:[~2021-05-02 14:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-02 14:05 [PATCH AUTOSEL 4.14 01/16] staging: wimax/i2400m: fix byte-order issue Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 02/16] crypto: api - check for ERR pointers in crypto_destroy_tfm() Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 03/16] usb: gadget: uvc: add bInterval checking for HS mode Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 04/16] usb: gadget: f_uac1: validate input parameters Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 05/16] usb: dwc3: gadget: Ignore EP queue requests during bus reset Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 06/16] usb: xhci: Fix port minor revision Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 07/16] PCI: PM: Do not read power state in pci_enable_device_flags() Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 08/16] x86/build: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS) Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 09/16] tee: optee: do not check memref size on return from Secure World Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 10/16] perf/arm_pmu_platform: Fix error handling Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 11/16] spi: dln2: Fix reference leak to master Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 12/16] spi: omap-100k: " Sasha Levin
2021-05-02 14:05 ` Sasha Levin [this message]
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 14/16] intel_th: Consistency and off-by-one fix Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 15/16] phy: phy-twl4030-usb: Fix possible use-after-free in twl4030_usb_remove() Sasha Levin
2021-05-02 14:05 ` [PATCH AUTOSEL 4.14 16/16] btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210502140544.2720138-13-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=hdegoede@redhat.com \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=markpearson@lenovo.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox