2019-05-27 14:55:12 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2007-05-08 23:22:02 +08:00
|
|
|
/*
|
|
|
|
* coretemp.c - Linux kernel module for hardware monitoring
|
|
|
|
*
|
|
|
|
* Copyright (C) 2007 Rudolf Marek <r.marek@assembler.cz>
|
|
|
|
*
|
|
|
|
* Inspired from many hwmon drivers
|
|
|
|
*/
|
|
|
|
|
2010-10-20 14:51:31 +08:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2007-05-08 23:22:02 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/jiffies.h>
|
|
|
|
#include <linux/hwmon.h>
|
|
|
|
#include <linux/sysfs.h>
|
|
|
|
#include <linux/hwmon-sysfs.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/cpu.h>
|
2011-05-20 05:45:48 +08:00
|
|
|
#include <linux/smp.h>
|
2011-09-17 03:24:02 +08:00
|
|
|
#include <linux/moduleparam.h>
|
2013-05-28 03:20:19 +08:00
|
|
|
#include <linux/pci.h>
|
2007-05-08 23:22:02 +08:00
|
|
|
#include <asm/msr.h>
|
|
|
|
#include <asm/processor.h>
|
2012-01-26 07:09:10 +08:00
|
|
|
#include <asm/cpu_device_id.h>
|
2022-12-17 04:24:08 +08:00
|
|
|
#include <linux/sched/isolation.h>
|
2007-05-08 23:22:02 +08:00
|
|
|
|
|
|
|
#define DRVNAME "coretemp"
|
|
|
|
|
2011-09-17 03:24:02 +08:00
|
|
|
/*
|
|
|
|
* force_tjmax only matters when TjMax can't be read from the CPU itself.
|
|
|
|
* When set, it replaces the driver's suboptimal heuristic.
|
|
|
|
*/
|
|
|
|
static int force_tjmax;
|
|
|
|
module_param_named(tjmax, force_tjmax, int, 0444);
|
|
|
|
MODULE_PARM_DESC(tjmax, "TjMax value in degrees Celsius");
|
|
|
|
|
2016-11-23 01:42:02 +08:00
|
|
|
#define PKG_SYSFS_ATTR_NO 1 /* Sysfs attribute for package temp */
|
2011-05-20 03:59:35 +08:00
|
|
|
#define BASE_SYSFS_ATTR_NO 2 /* Sysfs Base attr no for coretemp */
|
2015-10-12 19:53:32 +08:00
|
|
|
#define NUM_REAL_CORES 128 /* Number of Real cores per cpu */
|
hwmon: (coretemp) Fix potentially truncated sysfs attribute name
When build with W=1 and "-Werror=format-truncation", below error is
observed in coretemp driver,
drivers/hwmon/coretemp.c: In function 'create_core_data':
>> drivers/hwmon/coretemp.c:393:34: error: '%s' directive output may be truncated writing likely 5 or more bytes into a region of size between 3 and 13 [-Werror=format-truncation=]
393 | "temp%d_%s", attr_no, suffixes[i]);
| ^~
drivers/hwmon/coretemp.c:393:26: note: assuming directive output of 5 bytes
393 | "temp%d_%s", attr_no, suffixes[i]);
| ^~~~~~~~~~~
drivers/hwmon/coretemp.c:392:17: note: 'snprintf' output 7 or more bytes (assuming 22) into a destination of size 19
392 | snprintf(tdata->attr_name[i], CORETEMP_NAME_LENGTH,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
393 | "temp%d_%s", attr_no, suffixes[i]);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Given that
1. '%d' could take 10 charactors,
2. '%s' could take 10 charactors ("crit_alarm"),
3. "temp", "_" and the NULL terminator take 6 charactors,
fix the problem by increasing CORETEMP_NAME_LENGTH to 28.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310200443.iD3tUbbK-lkp@intel.com/
Link: https://lore.kernel.org/r/20231025122316.836400-1-rui.zhang@intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-10-25 20:23:16 +08:00
|
|
|
#define CORETEMP_NAME_LENGTH 28 /* String Length of attrs */
|
2011-07-12 19:07:16 +08:00
|
|
|
#define MAX_CORE_ATTRS 4 /* Maximum no of basic attrs */
|
hwmon: (coretemp) Don't use threshold registers for tempX_max
With commit c814a4c7c4aad795835583344353963a0a673eb0, the meaning of tempX_max
was changed. It no longer returns the value of bits 8:15 of
MSR_IA32_TEMPERATURE_TARGET, but instead returns the value of CPU threshold
register T1. tempX_max_hyst was added to reflect the value of temperature
threshold register T0.
As it turns out, T0 and T1 are used on some systems, presumably by the BIOS.
Also, T0 and T1 don't have a well defined meaning. The thresholds may be used
as upper or lower limits, and it is not guaranteed that T0 <= T1. Thus, the new
attribute mapping does not reflect the actual usage of the threshold registers.
Also, register contents are changed during runtime by an entity other than the
hwmon driver, meaning the values cached by the driver do not reflect actual
register contents.
Revert most of c814a4c7c4aad795835583344353963a0a673eb0 to address the problem.
Support for T0 and T1 will be added back in with a separate commit, using new
attribute names.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
2011-09-20 12:41:16 +08:00
|
|
|
#define TOTAL_ATTRS (MAX_CORE_ATTRS + 1)
|
2011-05-20 03:59:35 +08:00
|
|
|
#define MAX_CORE_DATA (NUM_REAL_CORES + BASE_SYSFS_ATTR_NO)
|
|
|
|
|
2011-12-21 08:52:22 +08:00
|
|
|
#ifdef CONFIG_SMP
|
2015-05-26 21:11:30 +08:00
|
|
|
#define for_each_sibling(i, cpu) \
|
|
|
|
for_each_cpu(i, topology_sibling_cpumask(cpu))
|
2011-05-20 03:59:35 +08:00
|
|
|
#else
|
2011-05-24 03:06:41 +08:00
|
|
|
#define for_each_sibling(i, cpu) for (i = 0; false; )
|
2011-05-20 03:59:35 +08:00
|
|
|
#endif
|
2007-05-08 23:22:02 +08:00
|
|
|
|
|
|
|
/*
|
2011-05-20 03:59:35 +08:00
|
|
|
* Per-Core Temperature Data
|
2022-11-13 23:31:44 +08:00
|
|
|
* @tjmax: The static tjmax value when tjmax cannot be retrieved from
|
|
|
|
* IA32_TEMPERATURE_TARGET MSR.
|
2011-05-20 03:59:35 +08:00
|
|
|
* @last_updated: The time when the current temperature value was updated
|
|
|
|
* earlier (in jiffies).
|
|
|
|
* @cpu_core_id: The CPU Core from which temperature values should be read
|
|
|
|
* This value is passed as "id" field to rdmsr/wrmsr functions.
|
|
|
|
* @status_reg: One of IA32_THERM_STATUS or IA32_PACKAGE_THERM_STATUS,
|
|
|
|
* from where the temperature values should be read.
|
2011-07-12 19:07:16 +08:00
|
|
|
* @attr_size: Total number of pre-core attrs displayed in the sysfs.
|
2011-05-20 03:59:35 +08:00
|
|
|
* @is_pkg_data: If this is 1, the temp_data holds pkgtemp data.
|
|
|
|
* Otherwise, temp_data holds coretemp data.
|
2007-05-08 23:22:02 +08:00
|
|
|
*/
|
2011-05-20 03:59:35 +08:00
|
|
|
struct temp_data {
|
2007-05-08 23:22:02 +08:00
|
|
|
int temp;
|
2011-05-20 03:59:35 +08:00
|
|
|
int tjmax;
|
|
|
|
unsigned long last_updated;
|
|
|
|
unsigned int cpu;
|
|
|
|
u32 cpu_core_id;
|
|
|
|
u32 status_reg;
|
2011-07-12 19:07:16 +08:00
|
|
|
int attr_size;
|
2011-05-20 03:59:35 +08:00
|
|
|
bool is_pkg_data;
|
2011-07-12 19:07:16 +08:00
|
|
|
struct sensor_device_attribute sd_attrs[TOTAL_ATTRS];
|
|
|
|
char attr_name[TOTAL_ATTRS][CORETEMP_NAME_LENGTH];
|
2014-02-17 05:23:25 +08:00
|
|
|
struct attribute *attrs[TOTAL_ATTRS + 1];
|
|
|
|
struct attribute_group attr_group;
|
2011-05-20 03:59:35 +08:00
|
|
|
struct mutex update_lock;
|
2007-05-08 23:22:02 +08:00
|
|
|
};
|
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/* Platform Data per Physical CPU */
|
|
|
|
struct platform_data {
|
2016-11-23 01:42:02 +08:00
|
|
|
struct device *hwmon_dev;
|
2016-11-23 01:42:06 +08:00
|
|
|
u16 pkg_id;
|
2022-10-14 17:01:45 +08:00
|
|
|
u16 cpu_map[NUM_REAL_CORES];
|
|
|
|
struct ida ida;
|
2016-11-23 01:42:02 +08:00
|
|
|
struct cpumask cpumask;
|
|
|
|
struct temp_data *core_data[MAX_CORE_DATA];
|
2011-05-20 03:59:35 +08:00
|
|
|
struct device_attribute name_attr;
|
|
|
|
};
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2013-05-28 03:20:19 +08:00
|
|
|
struct tjmax_pci {
|
|
|
|
unsigned int device;
|
|
|
|
int tjmax;
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct tjmax_pci tjmax_pci_table[] = {
|
2013-05-28 05:17:27 +08:00
|
|
|
{ 0x0708, 110000 }, /* CE41x0 (Sodaville ) */
|
2013-05-28 03:20:19 +08:00
|
|
|
{ 0x0c72, 102000 }, /* Atom S1240 (Centerton) */
|
|
|
|
{ 0x0c73, 95000 }, /* Atom S1220 (Centerton) */
|
|
|
|
{ 0x0c75, 95000 }, /* Atom S1260 (Centerton) */
|
|
|
|
};
|
|
|
|
|
2012-06-18 00:05:05 +08:00
|
|
|
struct tjmax {
|
|
|
|
char const *id;
|
|
|
|
int tjmax;
|
|
|
|
};
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static const struct tjmax tjmax_table[] = {
|
2012-10-10 04:23:57 +08:00
|
|
|
{ "CPU 230", 100000 }, /* Model 0x1c, stepping 2 */
|
|
|
|
{ "CPU 330", 125000 }, /* Model 0x1c, stepping 2 */
|
2012-06-18 00:05:05 +08:00
|
|
|
};
|
|
|
|
|
2012-10-10 03:45:23 +08:00
|
|
|
struct tjmax_model {
|
|
|
|
u8 model;
|
|
|
|
u8 mask;
|
|
|
|
int tjmax;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define ANY 0xff
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static const struct tjmax_model tjmax_model_table[] = {
|
2012-11-17 13:55:24 +08:00
|
|
|
{ 0x1c, 10, 100000 }, /* D4xx, K4xx, N4xx, D5xx, K5xx, N5xx */
|
2012-10-10 03:45:23 +08:00
|
|
|
{ 0x1c, ANY, 90000 }, /* Z5xx, N2xx, possibly others
|
|
|
|
* Note: Also matches 230 and 330,
|
|
|
|
* which are covered by tjmax_table
|
|
|
|
*/
|
|
|
|
{ 0x26, ANY, 90000 }, /* Atom Tunnel Creek (Exx), Lincroft (Z6xx)
|
|
|
|
* Note: TjMax for E6xxT is 110C, but CPU type
|
|
|
|
* is undetectable by software
|
|
|
|
*/
|
|
|
|
{ 0x27, ANY, 90000 }, /* Atom Medfield (Z2460) */
|
2013-05-28 03:20:19 +08:00
|
|
|
{ 0x35, ANY, 90000 }, /* Atom Clover Trail/Cloverview (Z27x0) */
|
|
|
|
{ 0x36, ANY, 100000 }, /* Atom Cedar Trail/Cedarview (N2xxx, D2xxx)
|
|
|
|
* Also matches S12x0 (stepping 9), covered by
|
|
|
|
* PCI table
|
|
|
|
*/
|
2012-10-10 03:45:23 +08:00
|
|
|
};
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static int adjust_tjmax(struct cpuinfo_x86 *c, u32 id, struct device *dev)
|
2008-02-18 05:59:39 +08:00
|
|
|
{
|
|
|
|
/* The 100C is default for both mobile and non mobile CPUs */
|
|
|
|
|
|
|
|
int tjmax = 100000;
|
2009-09-24 04:59:42 +08:00
|
|
|
int tjmax_ee = 85000;
|
2009-09-24 04:59:42 +08:00
|
|
|
int usemsr_ee = 1;
|
2008-02-18 05:59:39 +08:00
|
|
|
int err;
|
|
|
|
u32 eax, edx;
|
2012-06-18 00:05:05 +08:00
|
|
|
int i;
|
2017-11-22 13:30:56 +08:00
|
|
|
u16 devfn = PCI_DEVFN(0, 0);
|
|
|
|
struct pci_dev *host_bridge = pci_get_domain_bus_and_slot(0, 0, devfn);
|
2013-05-28 03:20:19 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Explicit tjmax table entries override heuristics.
|
|
|
|
* First try PCI host bridge IDs, followed by model ID strings
|
|
|
|
* and model/stepping information.
|
|
|
|
*/
|
|
|
|
if (host_bridge && host_bridge->vendor == PCI_VENDOR_ID_INTEL) {
|
|
|
|
for (i = 0; i < ARRAY_SIZE(tjmax_pci_table); i++) {
|
2022-11-18 17:33:03 +08:00
|
|
|
if (host_bridge->device == tjmax_pci_table[i].device) {
|
|
|
|
pci_dev_put(host_bridge);
|
2013-05-28 03:20:19 +08:00
|
|
|
return tjmax_pci_table[i].tjmax;
|
2022-11-18 17:33:03 +08:00
|
|
|
}
|
2013-05-28 03:20:19 +08:00
|
|
|
}
|
|
|
|
}
|
2022-11-18 17:33:03 +08:00
|
|
|
pci_dev_put(host_bridge);
|
2012-06-18 00:05:05 +08:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(tjmax_table); i++) {
|
|
|
|
if (strstr(c->x86_model_id, tjmax_table[i].id))
|
|
|
|
return tjmax_table[i].tjmax;
|
|
|
|
}
|
2008-02-18 05:59:39 +08:00
|
|
|
|
2012-10-10 03:45:23 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(tjmax_model_table); i++) {
|
|
|
|
const struct tjmax_model *tm = &tjmax_model_table[i];
|
|
|
|
if (c->x86_model == tm->model &&
|
2018-01-01 09:52:10 +08:00
|
|
|
(tm->mask == ANY || c->x86_stepping == tm->mask))
|
2012-10-10 03:45:23 +08:00
|
|
|
return tm->tjmax;
|
hwmon: (coretemp) Drop dependency on PCI for TjMax detection on Atom CPUs
So far, we use the NM10 Express Chipset PCI chip ID to detect TjMax for
Atom CPUs with model 0x1c. As it turns out, we can use the CPU stepping
(x86_mask) for the same purpose; stepping is 10 for all model 0x1c CPUs
with TjMax of 100 degrees C. This was verified by checking the output of
/proc/cpuinfo for the respective CPUs (D4xx, D5xx, N4xx, N5xx).
Other CPUs currently covered by the same code (Exx, Z6xx, Z2460) are not
supported by the NM10 Express Chipset. Most of those CPUs have TjMax of 90
degrees C, except for E6xxT models which have a TjMax of 110 degrees C.
E6xxT CPUs can however not be detected by software.
Calculate TjMax for Atom CPUs as follows. Note that the listed values are not
correct in some cases (230, 330). tjmax_table is used for those to override
the default values.
ID Stepping TjMax Models
0x1c 10 100 D4xx, N4xx, D5xx, N5xx
0x1c not 10 90 Z5xx, N2xx, 230, 330, others
0x26 - 90 Atom Tunnel Creek (Exx),
Lincroft (Z6xx)
0x27 - 90 Atom Medfield (Z2460)
0x36 - 100 Atom Cedar Trail (N2xxx, D2xxx)
Also drop the module dependency on PCI.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
2012-10-10 03:27:12 +08:00
|
|
|
}
|
2010-01-11 03:52:34 +08:00
|
|
|
|
hwmon: (coretemp) Drop dependency on PCI for TjMax detection on Atom CPUs
So far, we use the NM10 Express Chipset PCI chip ID to detect TjMax for
Atom CPUs with model 0x1c. As it turns out, we can use the CPU stepping
(x86_mask) for the same purpose; stepping is 10 for all model 0x1c CPUs
with TjMax of 100 degrees C. This was verified by checking the output of
/proc/cpuinfo for the respective CPUs (D4xx, D5xx, N4xx, N5xx).
Other CPUs currently covered by the same code (Exx, Z6xx, Z2460) are not
supported by the NM10 Express Chipset. Most of those CPUs have TjMax of 90
degrees C, except for E6xxT models which have a TjMax of 110 degrees C.
E6xxT CPUs can however not be detected by software.
Calculate TjMax for Atom CPUs as follows. Note that the listed values are not
correct in some cases (230, 330). tjmax_table is used for those to override
the default values.
ID Stepping TjMax Models
0x1c 10 100 D4xx, N4xx, D5xx, N5xx
0x1c not 10 90 Z5xx, N2xx, 230, 330, others
0x26 - 90 Atom Tunnel Creek (Exx),
Lincroft (Z6xx)
0x27 - 90 Atom Medfield (Z2460)
0x36 - 100 Atom Cedar Trail (N2xxx, D2xxx)
Also drop the module dependency on PCI.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
2012-10-10 03:27:12 +08:00
|
|
|
/* Early chips have no MSR for TjMax */
|
2010-01-11 03:52:34 +08:00
|
|
|
|
2018-01-01 09:52:10 +08:00
|
|
|
if (c->x86_model == 0xf && c->x86_stepping < 4)
|
2012-06-18 00:05:05 +08:00
|
|
|
usemsr_ee = 0;
|
2009-09-24 04:59:42 +08:00
|
|
|
|
2011-05-20 05:45:48 +08:00
|
|
|
if (c->x86_model > 0xe && usemsr_ee) {
|
2009-09-24 04:59:42 +08:00
|
|
|
u8 platform_id;
|
2008-02-18 05:59:39 +08:00
|
|
|
|
2011-05-20 05:45:48 +08:00
|
|
|
/*
|
|
|
|
* Now we can detect the mobile CPU using Intel provided table
|
|
|
|
* http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
|
|
|
|
* For Core2 cores, check MSR 0x17, bit 28 1 = Mobile CPU
|
|
|
|
*/
|
2008-02-18 05:59:39 +08:00
|
|
|
err = rdmsr_safe_on_cpu(id, 0x17, &eax, &edx);
|
|
|
|
if (err) {
|
|
|
|
dev_warn(dev,
|
|
|
|
"Unable to access MSR 0x17, assuming desktop"
|
|
|
|
" CPU\n");
|
2009-09-24 04:59:42 +08:00
|
|
|
usemsr_ee = 0;
|
2009-09-24 04:59:42 +08:00
|
|
|
} else if (c->x86_model < 0x17 && !(eax & 0x10000000)) {
|
2011-05-20 05:45:48 +08:00
|
|
|
/*
|
|
|
|
* Trust bit 28 up to Penryn, I could not find any
|
|
|
|
* documentation on that; if you happen to know
|
|
|
|
* someone at Intel please ask
|
|
|
|
*/
|
2009-09-24 04:59:42 +08:00
|
|
|
usemsr_ee = 0;
|
2009-09-24 04:59:42 +08:00
|
|
|
} else {
|
|
|
|
/* Platform ID bits 52:50 (EDX starts at bit 32) */
|
|
|
|
platform_id = (edx >> 18) & 0x7;
|
|
|
|
|
2011-05-20 05:45:48 +08:00
|
|
|
/*
|
|
|
|
* Mobile Penryn CPU seems to be platform ID 7 or 5
|
|
|
|
* (guesswork)
|
|
|
|
*/
|
|
|
|
if (c->x86_model == 0x17 &&
|
|
|
|
(platform_id == 5 || platform_id == 7)) {
|
|
|
|
/*
|
|
|
|
* If MSR EE bit is set, set it to 90 degrees C,
|
|
|
|
* otherwise 105 degrees C
|
|
|
|
*/
|
2009-09-24 04:59:42 +08:00
|
|
|
tjmax_ee = 90000;
|
|
|
|
tjmax = 105000;
|
|
|
|
}
|
2008-02-18 05:59:39 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-09-24 04:59:42 +08:00
|
|
|
if (usemsr_ee) {
|
2008-02-18 05:59:39 +08:00
|
|
|
err = rdmsr_safe_on_cpu(id, 0xee, &eax, &edx);
|
|
|
|
if (err) {
|
|
|
|
dev_warn(dev,
|
|
|
|
"Unable to access MSR 0xEE, for Tjmax, left"
|
2010-03-30 04:03:00 +08:00
|
|
|
" at default\n");
|
2008-02-18 05:59:39 +08:00
|
|
|
} else if (eax & 0x40000000) {
|
2009-09-24 04:59:42 +08:00
|
|
|
tjmax = tjmax_ee;
|
2008-02-18 05:59:39 +08:00
|
|
|
}
|
2009-09-24 04:59:42 +08:00
|
|
|
} else if (tjmax == 100000) {
|
2011-05-20 05:45:48 +08:00
|
|
|
/*
|
|
|
|
* If we don't use msr EE it means we are desktop CPU
|
|
|
|
* (with exeception of Atom)
|
|
|
|
*/
|
2008-02-18 05:59:39 +08:00
|
|
|
dev_warn(dev, "Using relative temperature scale!\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
return tjmax;
|
|
|
|
}
|
|
|
|
|
2013-05-28 05:12:15 +08:00
|
|
|
static bool cpu_has_tjmax(struct cpuinfo_x86 *c)
|
|
|
|
{
|
|
|
|
u8 model = c->x86_model;
|
|
|
|
|
|
|
|
return model > 0xe &&
|
|
|
|
model != 0x1c &&
|
|
|
|
model != 0x26 &&
|
|
|
|
model != 0x27 &&
|
|
|
|
model != 0x35 &&
|
|
|
|
model != 0x36;
|
|
|
|
}
|
|
|
|
|
2022-11-13 23:31:44 +08:00
|
|
|
static int get_tjmax(struct temp_data *tdata, struct device *dev)
|
2010-05-25 05:33:41 +08:00
|
|
|
{
|
2022-11-13 23:31:44 +08:00
|
|
|
struct cpuinfo_x86 *c = &cpu_data(tdata->cpu);
|
2010-05-25 05:33:41 +08:00
|
|
|
int err;
|
|
|
|
u32 eax, edx;
|
|
|
|
u32 val;
|
|
|
|
|
2022-11-13 23:31:44 +08:00
|
|
|
/* use static tjmax once it is set */
|
|
|
|
if (tdata->tjmax)
|
|
|
|
return tdata->tjmax;
|
|
|
|
|
2011-05-20 05:45:48 +08:00
|
|
|
/*
|
|
|
|
* A new feature of current Intel(R) processors, the
|
|
|
|
* IA32_TEMPERATURE_TARGET contains the TjMax value
|
|
|
|
*/
|
2022-11-13 23:31:44 +08:00
|
|
|
err = rdmsr_safe_on_cpu(tdata->cpu, MSR_IA32_TEMPERATURE_TARGET, &eax, &edx);
|
2010-05-25 05:33:41 +08:00
|
|
|
if (err) {
|
2013-05-28 05:12:15 +08:00
|
|
|
if (cpu_has_tjmax(c))
|
2022-11-13 23:31:44 +08:00
|
|
|
dev_warn(dev, "Unable to read TjMax from CPU %u\n", tdata->cpu);
|
2010-05-25 05:33:41 +08:00
|
|
|
} else {
|
2014-05-01 05:08:14 +08:00
|
|
|
val = (eax >> 16) & 0xff;
|
2023-03-30 18:33:45 +08:00
|
|
|
if (val)
|
2010-05-25 05:33:41 +08:00
|
|
|
return val * 1000;
|
|
|
|
}
|
|
|
|
|
2011-09-17 03:24:02 +08:00
|
|
|
if (force_tjmax) {
|
|
|
|
dev_notice(dev, "TjMax forced to %d degrees C by user\n",
|
|
|
|
force_tjmax);
|
2022-11-13 23:31:44 +08:00
|
|
|
tdata->tjmax = force_tjmax * 1000;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* An assumption is made for early CPUs and unreadable MSR.
|
|
|
|
* NOTE: the calculated value may not be correct.
|
|
|
|
*/
|
|
|
|
tdata->tjmax = adjust_tjmax(c, tdata->cpu, dev);
|
2011-09-17 03:24:02 +08:00
|
|
|
}
|
2022-11-13 23:31:44 +08:00
|
|
|
return tdata->tjmax;
|
2010-05-25 05:33:41 +08:00
|
|
|
}
|
|
|
|
|
2022-11-13 23:31:45 +08:00
|
|
|
static int get_ttarget(struct temp_data *tdata, struct device *dev)
|
|
|
|
{
|
|
|
|
u32 eax, edx;
|
|
|
|
int tjmax, ttarget_offset, ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ttarget is valid only if tjmax can be retrieved from
|
|
|
|
* MSR_IA32_TEMPERATURE_TARGET
|
|
|
|
*/
|
|
|
|
if (tdata->tjmax)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ret = rdmsr_safe_on_cpu(tdata->cpu, MSR_IA32_TEMPERATURE_TARGET, &eax, &edx);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
tjmax = (eax >> 16) & 0xff;
|
|
|
|
|
|
|
|
/* Read the still undocumented bits 8:15 of IA32_TEMPERATURE_TARGET. */
|
|
|
|
ttarget_offset = (eax >> 8) & 0xff;
|
|
|
|
|
|
|
|
return (tjmax - ttarget_offset) * 1000;
|
|
|
|
}
|
|
|
|
|
2022-11-13 23:31:43 +08:00
|
|
|
/* Keep track of how many zone pointers we allocated in init() */
|
|
|
|
static int max_zones __read_mostly;
|
|
|
|
/* Array of zone pointers. Serialized by cpu hotplug lock */
|
|
|
|
static struct platform_device **zone_devices;
|
|
|
|
|
|
|
|
static ssize_t show_label(struct device *dev,
|
|
|
|
struct device_attribute *devattr, char *buf)
|
|
|
|
{
|
|
|
|
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
|
|
|
|
struct platform_data *pdata = dev_get_drvdata(dev);
|
|
|
|
struct temp_data *tdata = pdata->core_data[attr->index];
|
|
|
|
|
|
|
|
if (tdata->is_pkg_data)
|
|
|
|
return sprintf(buf, "Package id %u\n", pdata->pkg_id);
|
|
|
|
|
|
|
|
return sprintf(buf, "Core %u\n", tdata->cpu_core_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t show_crit_alarm(struct device *dev,
|
|
|
|
struct device_attribute *devattr, char *buf)
|
|
|
|
{
|
|
|
|
u32 eax, edx;
|
|
|
|
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
|
|
|
|
struct platform_data *pdata = dev_get_drvdata(dev);
|
|
|
|
struct temp_data *tdata = pdata->core_data[attr->index];
|
|
|
|
|
|
|
|
mutex_lock(&tdata->update_lock);
|
|
|
|
rdmsr_on_cpu(tdata->cpu, tdata->status_reg, &eax, &edx);
|
|
|
|
mutex_unlock(&tdata->update_lock);
|
|
|
|
|
|
|
|
return sprintf(buf, "%d\n", (eax >> 5) & 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t show_tjmax(struct device *dev,
|
|
|
|
struct device_attribute *devattr, char *buf)
|
|
|
|
{
|
|
|
|
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
|
|
|
|
struct platform_data *pdata = dev_get_drvdata(dev);
|
2022-11-13 23:31:44 +08:00
|
|
|
struct temp_data *tdata = pdata->core_data[attr->index];
|
|
|
|
int tjmax;
|
|
|
|
|
|
|
|
mutex_lock(&tdata->update_lock);
|
|
|
|
tjmax = get_tjmax(tdata, dev);
|
|
|
|
mutex_unlock(&tdata->update_lock);
|
2022-11-13 23:31:43 +08:00
|
|
|
|
2022-11-13 23:31:44 +08:00
|
|
|
return sprintf(buf, "%d\n", tjmax);
|
2022-11-13 23:31:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t show_ttarget(struct device *dev,
|
|
|
|
struct device_attribute *devattr, char *buf)
|
|
|
|
{
|
|
|
|
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
|
|
|
|
struct platform_data *pdata = dev_get_drvdata(dev);
|
2022-11-13 23:31:45 +08:00
|
|
|
struct temp_data *tdata = pdata->core_data[attr->index];
|
|
|
|
int ttarget;
|
2022-11-13 23:31:43 +08:00
|
|
|
|
2022-11-13 23:31:45 +08:00
|
|
|
mutex_lock(&tdata->update_lock);
|
|
|
|
ttarget = get_ttarget(tdata, dev);
|
|
|
|
mutex_unlock(&tdata->update_lock);
|
|
|
|
|
|
|
|
if (ttarget < 0)
|
|
|
|
return ttarget;
|
|
|
|
return sprintf(buf, "%d\n", ttarget);
|
2022-11-13 23:31:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t show_temp(struct device *dev,
|
|
|
|
struct device_attribute *devattr, char *buf)
|
|
|
|
{
|
|
|
|
u32 eax, edx;
|
|
|
|
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
|
|
|
|
struct platform_data *pdata = dev_get_drvdata(dev);
|
|
|
|
struct temp_data *tdata = pdata->core_data[attr->index];
|
2022-11-13 23:31:44 +08:00
|
|
|
int tjmax;
|
2022-11-13 23:31:43 +08:00
|
|
|
|
|
|
|
mutex_lock(&tdata->update_lock);
|
|
|
|
|
2022-11-13 23:31:44 +08:00
|
|
|
tjmax = get_tjmax(tdata, dev);
|
2022-11-13 23:31:43 +08:00
|
|
|
/* Check whether the time interval has elapsed */
|
|
|
|
if (time_after(jiffies, tdata->last_updated + HZ)) {
|
|
|
|
rdmsr_on_cpu(tdata->cpu, tdata->status_reg, &eax, &edx);
|
|
|
|
/*
|
|
|
|
* Ignore the valid bit. In all observed cases the register
|
|
|
|
* value is either low or zero if the valid bit is 0.
|
|
|
|
* Return it instead of reporting an error which doesn't
|
|
|
|
* really help at all.
|
|
|
|
*/
|
2022-11-13 23:31:44 +08:00
|
|
|
tdata->temp = tjmax - ((eax >> 16) & 0x7f) * 1000;
|
2022-11-13 23:31:43 +08:00
|
|
|
tdata->last_updated = jiffies;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&tdata->update_lock);
|
|
|
|
return sprintf(buf, "%d\n", tdata->temp);
|
|
|
|
}
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static int create_core_attrs(struct temp_data *tdata, struct device *dev,
|
|
|
|
int attr_no)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
2014-02-17 05:23:25 +08:00
|
|
|
int i;
|
2011-09-23 18:36:53 +08:00
|
|
|
static ssize_t (*const rd_ptr[TOTAL_ATTRS]) (struct device *dev,
|
2011-05-20 03:59:35 +08:00
|
|
|
struct device_attribute *devattr, char *buf) = {
|
2011-07-12 19:07:16 +08:00
|
|
|
show_label, show_crit_alarm, show_temp, show_tjmax,
|
hwmon: (coretemp) Don't use threshold registers for tempX_max
With commit c814a4c7c4aad795835583344353963a0a673eb0, the meaning of tempX_max
was changed. It no longer returns the value of bits 8:15 of
MSR_IA32_TEMPERATURE_TARGET, but instead returns the value of CPU threshold
register T1. tempX_max_hyst was added to reflect the value of temperature
threshold register T0.
As it turns out, T0 and T1 are used on some systems, presumably by the BIOS.
Also, T0 and T1 don't have a well defined meaning. The thresholds may be used
as upper or lower limits, and it is not guaranteed that T0 <= T1. Thus, the new
attribute mapping does not reflect the actual usage of the threshold registers.
Also, register contents are changed during runtime by an entity other than the
hwmon driver, meaning the values cached by the driver do not reflect actual
register contents.
Revert most of c814a4c7c4aad795835583344353963a0a673eb0 to address the problem.
Support for T0 and T1 will be added back in with a separate commit, using new
attribute names.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
2011-09-20 12:41:16 +08:00
|
|
|
show_ttarget };
|
2015-02-12 22:15:16 +08:00
|
|
|
static const char *const suffixes[TOTAL_ATTRS] = {
|
|
|
|
"label", "crit_alarm", "input", "crit", "max"
|
|
|
|
};
|
2011-05-20 03:59:35 +08:00
|
|
|
|
2011-07-12 19:07:16 +08:00
|
|
|
for (i = 0; i < tdata->attr_size; i++) {
|
2015-02-12 22:15:16 +08:00
|
|
|
snprintf(tdata->attr_name[i], CORETEMP_NAME_LENGTH,
|
|
|
|
"temp%d_%s", attr_no, suffixes[i]);
|
2011-05-24 19:28:31 +08:00
|
|
|
sysfs_attr_init(&tdata->sd_attrs[i].dev_attr.attr);
|
2011-05-20 03:59:35 +08:00
|
|
|
tdata->sd_attrs[i].dev_attr.attr.name = tdata->attr_name[i];
|
2018-12-11 06:02:04 +08:00
|
|
|
tdata->sd_attrs[i].dev_attr.attr.mode = 0444;
|
2011-05-20 03:59:35 +08:00
|
|
|
tdata->sd_attrs[i].dev_attr.show = rd_ptr[i];
|
|
|
|
tdata->sd_attrs[i].index = attr_no;
|
2014-02-17 05:23:25 +08:00
|
|
|
tdata->attrs[i] = &tdata->sd_attrs[i].dev_attr.attr;
|
2007-05-08 23:22:02 +08:00
|
|
|
}
|
2014-02-17 05:23:25 +08:00
|
|
|
tdata->attr_group.attrs = tdata->attrs;
|
|
|
|
return sysfs_create_group(&dev->kobj, &tdata->attr_group);
|
2011-05-20 03:59:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static int chk_ucode_version(unsigned int cpu)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
2011-09-28 23:11:00 +08:00
|
|
|
struct cpuinfo_x86 *c = &cpu_data(cpu);
|
2007-05-28 04:17:43 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/*
|
|
|
|
* Check if we have problem with errata AE18 of Core processors:
|
|
|
|
* Readings might stop update when processor visited too deep sleep,
|
|
|
|
* fixed for stepping D0 (6EC).
|
|
|
|
*/
|
2018-01-01 09:52:10 +08:00
|
|
|
if (c->x86_model == 0xe && c->x86_stepping < 0xc && c->microcode < 0x39) {
|
2013-01-11 02:01:24 +08:00
|
|
|
pr_err("Errata AE18 not fixed, update BIOS or microcode of the CPU!\n");
|
2011-10-13 08:46:35 +08:00
|
|
|
return -ENODEV;
|
2007-05-28 04:17:43 +08:00
|
|
|
}
|
2011-05-20 03:59:35 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static struct platform_device *coretemp_get_pdev(unsigned int cpu)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
2019-05-14 01:59:01 +08:00
|
|
|
int id = topology_logical_die_id(cpu);
|
2011-05-20 03:59:35 +08:00
|
|
|
|
2019-05-14 01:59:01 +08:00
|
|
|
if (id >= 0 && id < max_zones)
|
|
|
|
return zone_devices[id];
|
2011-05-20 03:59:35 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static struct temp_data *init_temp_data(unsigned int cpu, int pkg_flag)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
|
|
|
struct temp_data *tdata;
|
|
|
|
|
|
|
|
tdata = kzalloc(sizeof(struct temp_data), GFP_KERNEL);
|
|
|
|
if (!tdata)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
tdata->status_reg = pkg_flag ? MSR_IA32_PACKAGE_THERM_STATUS :
|
|
|
|
MSR_IA32_THERM_STATUS;
|
|
|
|
tdata->is_pkg_data = pkg_flag;
|
|
|
|
tdata->cpu = cpu;
|
2022-10-14 17:01:45 +08:00
|
|
|
tdata->cpu_core_id = topology_core_id(cpu);
|
2011-07-12 19:07:16 +08:00
|
|
|
tdata->attr_size = MAX_CORE_ATTRS;
|
2011-05-20 03:59:35 +08:00
|
|
|
mutex_init(&tdata->update_lock);
|
|
|
|
return tdata;
|
|
|
|
}
|
2007-05-28 04:17:43 +08:00
|
|
|
|
2013-06-20 02:02:20 +08:00
|
|
|
static int create_core_data(struct platform_device *pdev, unsigned int cpu,
|
|
|
|
int pkg_flag)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
|
|
|
struct temp_data *tdata;
|
2011-09-23 18:40:08 +08:00
|
|
|
struct platform_data *pdata = platform_get_drvdata(pdev);
|
2011-05-20 03:59:35 +08:00
|
|
|
struct cpuinfo_x86 *c = &cpu_data(cpu);
|
|
|
|
u32 eax, edx;
|
2022-11-13 23:31:45 +08:00
|
|
|
int err, index, attr_no;
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2022-12-17 04:24:08 +08:00
|
|
|
if (!housekeeping_cpu(cpu, HK_TYPE_MISC))
|
|
|
|
return 0;
|
|
|
|
|
2010-05-25 05:33:41 +08:00
|
|
|
/*
|
2011-05-20 03:59:35 +08:00
|
|
|
* Find attr number for sysfs:
|
|
|
|
* We map the attr number to core id of the CPU
|
|
|
|
* The attr number is always core id + 2
|
|
|
|
* The Pkgtemp will always show up as temp1_*, if available
|
2010-05-25 05:33:41 +08:00
|
|
|
*/
|
2022-10-14 17:01:45 +08:00
|
|
|
if (pkg_flag) {
|
|
|
|
attr_no = PKG_SYSFS_ATTR_NO;
|
|
|
|
} else {
|
|
|
|
index = ida_alloc(&pdata->ida, GFP_KERNEL);
|
|
|
|
if (index < 0)
|
|
|
|
return index;
|
|
|
|
pdata->cpu_map[index] = topology_core_id(cpu);
|
|
|
|
attr_no = index + BASE_SYSFS_ATTR_NO;
|
|
|
|
}
|
2008-01-18 07:42:54 +08:00
|
|
|
|
2022-10-14 17:01:45 +08:00
|
|
|
if (attr_no > MAX_CORE_DATA - 1) {
|
|
|
|
err = -ERANGE;
|
|
|
|
goto ida_free;
|
|
|
|
}
|
2011-05-20 03:59:35 +08:00
|
|
|
|
|
|
|
tdata = init_temp_data(cpu, pkg_flag);
|
2022-10-14 17:01:45 +08:00
|
|
|
if (!tdata) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto ida_free;
|
|
|
|
}
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/* Test if we can access the status register */
|
|
|
|
err = rdmsr_safe_on_cpu(cpu, tdata->status_reg, &eax, &edx);
|
|
|
|
if (err)
|
|
|
|
goto exit_free;
|
|
|
|
|
2022-11-13 23:31:45 +08:00
|
|
|
/* Make sure tdata->tjmax is a valid indicator for dynamic/static tjmax */
|
|
|
|
get_tjmax(tdata, &pdev->dev);
|
2011-05-20 03:59:35 +08:00
|
|
|
|
2011-07-12 19:07:16 +08:00
|
|
|
/*
|
2022-11-13 23:31:45 +08:00
|
|
|
* The target temperature is available on older CPUs but not in the
|
|
|
|
* MSR_IA32_TEMPERATURE_TARGET register. Atoms don't have the register
|
|
|
|
* at all.
|
2011-07-12 19:07:16 +08:00
|
|
|
*/
|
2022-11-13 23:31:45 +08:00
|
|
|
if (c->x86_model > 0xe && c->x86_model != 0x1c)
|
|
|
|
if (get_ttarget(tdata, &pdev->dev) >= 0)
|
hwmon: (coretemp) Don't use threshold registers for tempX_max
With commit c814a4c7c4aad795835583344353963a0a673eb0, the meaning of tempX_max
was changed. It no longer returns the value of bits 8:15 of
MSR_IA32_TEMPERATURE_TARGET, but instead returns the value of CPU threshold
register T1. tempX_max_hyst was added to reflect the value of temperature
threshold register T0.
As it turns out, T0 and T1 are used on some systems, presumably by the BIOS.
Also, T0 and T1 don't have a well defined meaning. The thresholds may be used
as upper or lower limits, and it is not guaranteed that T0 <= T1. Thus, the new
attribute mapping does not reflect the actual usage of the threshold registers.
Also, register contents are changed during runtime by an entity other than the
hwmon driver, meaning the values cached by the driver do not reflect actual
register contents.
Revert most of c814a4c7c4aad795835583344353963a0a673eb0 to address the problem.
Support for T0 and T1 will be added back in with a separate commit, using new
attribute names.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
2011-09-20 12:41:16 +08:00
|
|
|
tdata->attr_size++;
|
2011-07-12 19:07:16 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
pdata->core_data[attr_no] = tdata;
|
|
|
|
|
|
|
|
/* Create sysfs interfaces */
|
2014-02-17 07:49:04 +08:00
|
|
|
err = create_core_attrs(tdata, pdata->hwmon_dev, attr_no);
|
2011-05-20 03:59:35 +08:00
|
|
|
if (err)
|
|
|
|
goto exit_free;
|
2007-05-08 23:22:02 +08:00
|
|
|
|
|
|
|
return 0;
|
2011-05-20 03:59:35 +08:00
|
|
|
exit_free:
|
2011-09-25 06:27:04 +08:00
|
|
|
pdata->core_data[attr_no] = NULL;
|
2011-05-20 03:59:35 +08:00
|
|
|
kfree(tdata);
|
2022-10-14 17:01:45 +08:00
|
|
|
ida_free:
|
|
|
|
if (!pkg_flag)
|
|
|
|
ida_free(&pdata->ida, index);
|
2011-05-20 03:59:35 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2016-11-23 01:42:03 +08:00
|
|
|
static void
|
|
|
|
coretemp_add_core(struct platform_device *pdev, unsigned int cpu, int pkg_flag)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
2016-11-23 01:42:03 +08:00
|
|
|
if (create_core_data(pdev, cpu, pkg_flag))
|
2011-05-20 03:59:35 +08:00
|
|
|
dev_err(&pdev->dev, "Adding Core %u failed\n", cpu);
|
|
|
|
}
|
|
|
|
|
2016-11-23 01:42:03 +08:00
|
|
|
static void coretemp_remove_core(struct platform_data *pdata, int indx)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
|
|
|
struct temp_data *tdata = pdata->core_data[indx];
|
|
|
|
|
2022-11-18 00:23:13 +08:00
|
|
|
/* if we errored on add then this is already gone */
|
|
|
|
if (!tdata)
|
|
|
|
return;
|
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/* Remove the sysfs attributes */
|
2014-02-17 07:49:04 +08:00
|
|
|
sysfs_remove_group(&pdata->hwmon_dev->kobj, &tdata->attr_group);
|
2011-05-20 03:59:35 +08:00
|
|
|
|
|
|
|
kfree(pdata->core_data[indx]);
|
|
|
|
pdata->core_data[indx] = NULL;
|
2022-10-14 17:01:45 +08:00
|
|
|
|
|
|
|
if (indx >= BASE_SYSFS_ATTR_NO)
|
|
|
|
ida_free(&pdata->ida, indx - BASE_SYSFS_ATTR_NO);
|
2011-05-20 03:59:35 +08:00
|
|
|
}
|
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
static int coretemp_device_add(int zoneid)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
struct platform_device *pdev;
|
2011-05-20 03:59:35 +08:00
|
|
|
struct platform_data *pdata;
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
int err;
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2019-05-14 01:59:01 +08:00
|
|
|
/* Initialize the per-zone data structures */
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
|
2011-05-20 03:59:35 +08:00
|
|
|
if (!pdata)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
pdata->pkg_id = zoneid;
|
2022-10-14 17:01:45 +08:00
|
|
|
ida_init(&pdata->ida);
|
2011-05-20 03:59:35 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
pdev = platform_device_alloc(DRVNAME, zoneid);
|
|
|
|
if (!pdev) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto err_free_pdata;
|
|
|
|
}
|
2007-05-08 23:22:02 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
err = platform_device_add(pdev);
|
|
|
|
if (err)
|
|
|
|
goto err_put_dev;
|
2011-05-20 03:59:35 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
platform_set_drvdata(pdev, pdata);
|
|
|
|
zone_devices[zoneid] = pdev;
|
2007-05-08 23:22:02 +08:00
|
|
|
return 0;
|
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
err_put_dev:
|
|
|
|
platform_device_put(pdev);
|
|
|
|
err_free_pdata:
|
|
|
|
kfree(pdata);
|
|
|
|
return err;
|
|
|
|
}
|
2007-05-08 23:22:02 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
static void coretemp_device_remove(int zoneid)
|
2007-05-08 23:22:02 +08:00
|
|
|
{
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
struct platform_device *pdev = zone_devices[zoneid];
|
|
|
|
struct platform_data *pdata = platform_get_drvdata(pdev);
|
2007-05-08 23:22:02 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
ida_destroy(&pdata->ida);
|
|
|
|
kfree(pdata);
|
|
|
|
platform_device_unregister(pdev);
|
2007-05-08 23:22:02 +08:00
|
|
|
}
|
|
|
|
|
2016-11-23 01:42:04 +08:00
|
|
|
static int coretemp_cpu_online(unsigned int cpu)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
|
|
|
struct platform_device *pdev = coretemp_get_pdev(cpu);
|
2016-11-23 01:42:02 +08:00
|
|
|
struct cpuinfo_x86 *c = &cpu_data(cpu);
|
|
|
|
struct platform_data *pdata;
|
2011-05-20 03:59:35 +08:00
|
|
|
|
2017-05-10 22:30:12 +08:00
|
|
|
/*
|
|
|
|
* Don't execute this on resume as the offline callback did
|
|
|
|
* not get executed on suspend.
|
|
|
|
*/
|
|
|
|
if (cpuhp_tasks_frozen)
|
|
|
|
return 0;
|
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/*
|
|
|
|
* CPUID.06H.EAX[0] indicates whether the CPU has thermal
|
|
|
|
* sensors. We check this bit only, all the early CPUs
|
|
|
|
* without thermal sensors will be filtered out.
|
|
|
|
*/
|
2012-06-23 01:58:06 +08:00
|
|
|
if (!cpu_has(c, X86_FEATURE_DTHERM))
|
2016-11-23 01:42:05 +08:00
|
|
|
return -ENODEV;
|
2011-05-20 03:59:35 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
pdata = platform_get_drvdata(pdev);
|
|
|
|
if (!pdata->hwmon_dev) {
|
|
|
|
struct device *hwmon;
|
|
|
|
|
2011-09-28 23:11:00 +08:00
|
|
|
/* Check the microcode version of the CPU */
|
|
|
|
if (chk_ucode_version(cpu))
|
2016-11-23 01:42:05 +08:00
|
|
|
return -EINVAL;
|
2011-09-28 23:11:00 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/*
|
|
|
|
* Alright, we have DTS support.
|
|
|
|
* We are bringing the _first_ core in this pkg
|
|
|
|
* online. So, initialize per-pkg data structures and
|
|
|
|
* then bring this core online.
|
|
|
|
*/
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
hwmon = hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
|
|
|
|
pdata, NULL);
|
|
|
|
if (IS_ERR(hwmon))
|
|
|
|
return PTR_ERR(hwmon);
|
|
|
|
pdata->hwmon_dev = hwmon;
|
2016-11-23 01:42:02 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/*
|
|
|
|
* Check whether pkgtemp support is available.
|
|
|
|
* If so, add interfaces for pkgtemp.
|
|
|
|
*/
|
|
|
|
if (cpu_has(c, X86_FEATURE_PTS))
|
2016-11-23 01:42:03 +08:00
|
|
|
coretemp_add_core(pdev, cpu, 1);
|
2011-05-20 03:59:35 +08:00
|
|
|
}
|
2016-11-23 01:42:02 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/*
|
2016-11-23 01:42:02 +08:00
|
|
|
* Check whether a thread sibling is already online. If not add the
|
|
|
|
* interface for this CPU core.
|
2011-05-20 03:59:35 +08:00
|
|
|
*/
|
2016-11-23 01:42:02 +08:00
|
|
|
if (!cpumask_intersects(&pdata->cpumask, topology_sibling_cpumask(cpu)))
|
2016-11-23 01:42:03 +08:00
|
|
|
coretemp_add_core(pdev, cpu, 0);
|
2016-11-23 01:42:02 +08:00
|
|
|
|
|
|
|
cpumask_set_cpu(cpu, &pdata->cpumask);
|
2016-11-23 01:42:04 +08:00
|
|
|
return 0;
|
2011-05-20 03:59:35 +08:00
|
|
|
}
|
|
|
|
|
2016-11-23 01:42:04 +08:00
|
|
|
static int coretemp_cpu_offline(unsigned int cpu)
|
2011-05-20 03:59:35 +08:00
|
|
|
{
|
|
|
|
struct platform_device *pdev = coretemp_get_pdev(cpu);
|
2016-11-23 01:42:02 +08:00
|
|
|
struct platform_data *pd;
|
2016-11-23 01:42:02 +08:00
|
|
|
struct temp_data *tdata;
|
2022-10-14 17:01:45 +08:00
|
|
|
int i, indx = -1, target;
|
2011-05-20 03:59:35 +08:00
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
/* No need to tear down any interfaces for suspend */
|
2017-05-10 22:30:12 +08:00
|
|
|
if (cpuhp_tasks_frozen)
|
|
|
|
return 0;
|
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/* If the physical CPU device does not exist, just return */
|
2022-10-14 17:01:45 +08:00
|
|
|
pd = platform_get_drvdata(pdev);
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
if (!pd->hwmon_dev)
|
|
|
|
return 0;
|
2022-10-14 17:01:45 +08:00
|
|
|
|
|
|
|
for (i = 0; i < NUM_REAL_CORES; i++) {
|
|
|
|
if (pd->cpu_map[i] == topology_core_id(cpu)) {
|
|
|
|
indx = i + BASE_SYSFS_ATTR_NO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Too many cores and this core is not populated, just return */
|
|
|
|
if (indx < 0)
|
2016-11-23 01:42:04 +08:00
|
|
|
return 0;
|
2012-04-30 21:18:01 +08:00
|
|
|
|
2016-11-23 01:42:02 +08:00
|
|
|
tdata = pd->core_data[indx];
|
|
|
|
|
|
|
|
cpumask_clear_cpu(cpu, &pd->cpumask);
|
2011-05-20 03:59:35 +08:00
|
|
|
|
2011-05-24 05:05:38 +08:00
|
|
|
/*
|
2016-11-23 01:42:02 +08:00
|
|
|
* If this is the last thread sibling, remove the CPU core
|
|
|
|
* interface, If there is still a sibling online, transfer the
|
|
|
|
* target cpu of that core interface to it.
|
2011-05-24 05:05:38 +08:00
|
|
|
*/
|
2016-11-23 01:42:02 +08:00
|
|
|
target = cpumask_any_and(&pd->cpumask, topology_sibling_cpumask(cpu));
|
|
|
|
if (target >= nr_cpu_ids) {
|
|
|
|
coretemp_remove_core(pd, indx);
|
|
|
|
} else if (tdata && tdata->cpu == cpu) {
|
|
|
|
mutex_lock(&tdata->update_lock);
|
|
|
|
tdata->cpu = target;
|
|
|
|
mutex_unlock(&tdata->update_lock);
|
2011-05-20 03:59:35 +08:00
|
|
|
}
|
2016-11-23 01:42:02 +08:00
|
|
|
|
2011-05-20 03:59:35 +08:00
|
|
|
/*
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
* If all cores in this pkg are offline, remove the interface.
|
2011-05-20 03:59:35 +08:00
|
|
|
*/
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
tdata = pd->core_data[PKG_SYSFS_ATTR_NO];
|
2016-11-23 01:42:02 +08:00
|
|
|
if (cpumask_empty(&pd->cpumask)) {
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
if (tdata)
|
|
|
|
coretemp_remove_core(pd, PKG_SYSFS_ATTR_NO);
|
|
|
|
hwmon_device_unregister(pd->hwmon_dev);
|
|
|
|
pd->hwmon_dev = NULL;
|
2016-11-23 01:42:04 +08:00
|
|
|
return 0;
|
2016-11-23 01:42:02 +08:00
|
|
|
}
|
2016-11-23 01:42:06 +08:00
|
|
|
|
2016-11-23 01:42:02 +08:00
|
|
|
/*
|
|
|
|
* Check whether this core is the target for the package
|
|
|
|
* interface. We need to assign it to some other cpu.
|
|
|
|
*/
|
|
|
|
if (tdata && tdata->cpu == cpu) {
|
2016-11-23 01:42:02 +08:00
|
|
|
target = cpumask_first(&pd->cpumask);
|
2016-11-23 01:42:02 +08:00
|
|
|
mutex_lock(&tdata->update_lock);
|
|
|
|
tdata->cpu = target;
|
|
|
|
mutex_unlock(&tdata->update_lock);
|
|
|
|
}
|
2016-11-23 01:42:04 +08:00
|
|
|
return 0;
|
2011-05-20 03:59:35 +08:00
|
|
|
}
|
2012-07-30 17:33:00 +08:00
|
|
|
static const struct x86_cpu_id __initconst coretemp_ids[] = {
|
2020-03-20 21:13:57 +08:00
|
|
|
X86_MATCH_VENDOR_FEATURE(INTEL, X86_FEATURE_DTHERM, NULL),
|
2012-01-26 07:09:10 +08:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(x86cpu, coretemp_ids);
|
|
|
|
|
2016-11-23 01:42:04 +08:00
|
|
|
static enum cpuhp_state coretemp_hp_online;
|
|
|
|
|
2007-05-08 23:22:02 +08:00
|
|
|
static int __init coretemp_init(void)
|
|
|
|
{
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
int i, err;
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2012-01-26 07:09:10 +08:00
|
|
|
/*
|
|
|
|
* CPUID.06H.EAX[0] indicates whether the CPU has thermal
|
|
|
|
* sensors. We check this bit only, all the early CPUs
|
|
|
|
* without thermal sensors will be filtered out.
|
|
|
|
*/
|
|
|
|
if (!x86_match_cpu(coretemp_ids))
|
|
|
|
return -ENODEV;
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2019-05-14 01:59:01 +08:00
|
|
|
max_zones = topology_max_packages() * topology_max_die_per_package();
|
|
|
|
zone_devices = kcalloc(max_zones, sizeof(struct platform_device *),
|
2016-11-23 01:42:06 +08:00
|
|
|
GFP_KERNEL);
|
2019-05-14 01:59:01 +08:00
|
|
|
if (!zone_devices)
|
2016-11-23 01:42:06 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
for (i = 0; i < max_zones; i++) {
|
|
|
|
err = coretemp_device_add(i);
|
|
|
|
if (err)
|
|
|
|
goto outzone;
|
|
|
|
}
|
2007-05-08 23:22:02 +08:00
|
|
|
|
2016-11-23 01:42:04 +08:00
|
|
|
err = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "hwmon/coretemp:online",
|
|
|
|
coretemp_cpu_online, coretemp_cpu_offline);
|
|
|
|
if (err < 0)
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
goto outzone;
|
2016-11-23 01:42:04 +08:00
|
|
|
coretemp_hp_online = err;
|
2007-05-08 23:22:02 +08:00
|
|
|
return 0;
|
|
|
|
|
2019-08-20 05:00:02 +08:00
|
|
|
outzone:
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
while (i--)
|
|
|
|
coretemp_device_remove(i);
|
2019-05-14 01:59:01 +08:00
|
|
|
kfree(zone_devices);
|
2007-05-08 23:22:02 +08:00
|
|
|
return err;
|
|
|
|
}
|
2016-11-23 01:42:04 +08:00
|
|
|
module_init(coretemp_init)
|
2007-05-08 23:22:02 +08:00
|
|
|
|
|
|
|
static void __exit coretemp_exit(void)
|
|
|
|
{
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
int i;
|
|
|
|
|
2016-11-23 01:42:04 +08:00
|
|
|
cpuhp_remove_state(coretemp_hp_online);
|
hwmon: (coretemp) Simplify platform device handling
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2023-01-03 19:46:20 +08:00
|
|
|
for (i = 0; i < max_zones; i++)
|
|
|
|
coretemp_device_remove(i);
|
2019-05-14 01:59:01 +08:00
|
|
|
kfree(zone_devices);
|
2007-05-08 23:22:02 +08:00
|
|
|
}
|
2016-11-23 01:42:04 +08:00
|
|
|
module_exit(coretemp_exit)
|
2007-05-08 23:22:02 +08:00
|
|
|
|
|
|
|
MODULE_AUTHOR("Rudolf Marek <r.marek@assembler.cz>");
|
|
|
|
MODULE_DESCRIPTION("Intel Core temperature monitor");
|
|
|
|
MODULE_LICENSE("GPL");
|