| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4b89a62f-adc0-4eef-8e49-638371fbadf0@roeck-us.net>
Date: Mon, 11 Aug 2025 07:03:05 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Chuande Chen <chenchuande@...il.com>, jdelvare@...e.com
Cc: linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
chuachen@...co.com, groeck7@...il.com
Subject: Re: [PATCH v2 1/1] hwmon: sbtsi_temp: AMD CPU extended temperature
range support
On 8/10/25 22:07, Chuande Chen wrote:
> From: Chuande Chen <chuachen@...co.com>
>
Any reason for not sending this from your Cisco e-mail address ?
> Many AMD CPUs can support this feature now.
> We would get a wrong CPU DIE temp if don't consider this.
temperature.
> In low-temperature environments, the CPU die temperature
> can drop below zero.
> So many platform would like to make extended temperature range
> as their default configuration.
> Default temperature range (0C to 255.875C) degree celsius.
> Extended temperature range (-49C to +206.875C) degree celsius.
Celsius. But then "C" and "degree celsius" is redundant and "degree celsius"
can be dropped.
> Ref Doc: AMD V3000 PPR (Doc ID #56558).
>
The document is not available to the public. You will need to find someone
from AMD to provide an Acked-by: or Reviewed-by: tag to show me that the
V3000 hardware really uses this bit.
The column limit for patch descriptions is 75 characters. Please use it.
> Signed-off-by: Chuande Chen <chuachen@...co.com>
> ---
> V1 -> V2: addressed review comments, also save READ_ORDER bit into sbtsi_data
> ---
> drivers/hwmon/sbtsi_temp.c | 46 +++++++++++++++++++++++++++-----------
> 1 file changed, 33 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
> index 3c839f56c..32d6a7162 100644
> --- a/drivers/hwmon/sbtsi_temp.c
> +++ b/drivers/hwmon/sbtsi_temp.c
> @@ -5,6 +5,7 @@
> *
> * Copyright (c) 2020, Google Inc.
> * Copyright (c) 2020, Kun Yi <kunyi@...gle.com>
> + * Copyright (c) 2025, Chuande Chen <chuachen@...co.com>
For adding a few lines of code ? If everyone would do that, the Linux kernel
code would consist of 50% or more copyright lines. If you insist on this,
I'll have to try and find official guidelines about if and when it is appropriate
to add copyrights.
Plus this made me suspicious: How do I know that you are really a Cisco employee
and not someone who tries to sneak in some code that isn't even supported
by real hardware ?
> */
>
> #include <linux/err.h>
> @@ -14,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/mutex.h>
> #include <linux/of.h>
> +#include <linux/bitfield.h>
>
> /*
> * SB-TSI registers only support SMBus byte data access. "_INT" registers are
> @@ -29,8 +31,23 @@
> #define SBTSI_REG_TEMP_HIGH_DEC 0x13 /* RW */
> #define SBTSI_REG_TEMP_LOW_DEC 0x14 /* RW */
>
> +/*
> + * Bit for reporting value with temperature measurement range.
> + * bit == 0: Use default temperature range (0C to 255.875C).
> + * bit == 1: Use extended temperature range (-49C to +206.875C).
> + */
> +#define SBTSI_CONFIG_EXT_RANGE_SHIFT 2
> +/*
> + * ReadOrder bit specifies the reading order of integer and
> + * decimal part of CPU temp for atomic reads. If bit == 0,
> + * reading integer part triggers latching of the decimal part,
> + * so integer part should be read first. If bit == 1, read
> + * order should be reversed.
> + */
Too many line splits. Extend lines to 80 characters. Yes, I see this is copied
from below, but that doesn't mean it can not be adjusted.
> #define SBTSI_CONFIG_READ_ORDER_SHIFT 5
>
> +#define SBTSI_TEMP_EXT_RANGE_ADJ 49000
> +
> #define SBTSI_TEMP_MIN 0
> #define SBTSI_TEMP_MAX 255875
>
> @@ -38,6 +55,8 @@
> struct sbtsi_data {
> struct i2c_client *client;
> struct mutex lock;
> + bool ext_range_mode;
> + bool read_order;
> };
>
> /*
> @@ -74,23 +93,11 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
> {
> struct sbtsi_data *data = dev_get_drvdata(dev);
> s32 temp_int, temp_dec;
> - int err;
>
> switch (attr) {
> case hwmon_temp_input:
> - /*
> - * ReadOrder bit specifies the reading order of integer and
> - * decimal part of CPU temp for atomic reads. If bit == 0,
> - * reading integer part triggers latching of the decimal part,
> - * so integer part should be read first. If bit == 1, read
> - * order should be reversed.
> - */
> - err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> - if (err < 0)
> - return err;
> -
> mutex_lock(&data->lock);
> - if (err & BIT(SBTSI_CONFIG_READ_ORDER_SHIFT)) {
> + if (data->read_order) {
> temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_DEC);
> temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_INT);
> } else {
> @@ -122,6 +129,8 @@ static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
> return temp_dec;
>
> *val = sbtsi_reg_to_mc(temp_int, temp_dec);
> + if (data->ext_range_mode)
> + *val -= SBTSI_TEMP_EXT_RANGE_ADJ;
>
> return 0;
> }
> @@ -146,6 +155,8 @@ static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
> return -EINVAL;
> }
>
> + if (data->ext_range_mode)
> + val += SBTSI_TEMP_EXT_RANGE_ADJ;
> val = clamp_val(val, SBTSI_TEMP_MIN, SBTSI_TEMP_MAX);
> sbtsi_mc_to_reg(val, &temp_int, &temp_dec);
>
> @@ -203,6 +214,7 @@ static int sbtsi_probe(struct i2c_client *client)
> struct device *dev = &client->dev;
> struct device *hwmon_dev;
> struct sbtsi_data *data;
> + int err;
>
> data = devm_kzalloc(dev, sizeof(struct sbtsi_data), GFP_KERNEL);
> if (!data)
> @@ -214,6 +226,14 @@ static int sbtsi_probe(struct i2c_client *client)
> hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data, &sbtsi_chip_info,
> NULL);
>
> + mutex_lock(&data->lock);
> + err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
> + mutex_unlock(&data->lock);
Unnecessary lock. First, this is in the probe function, where a lock is not needed
in the first place. Second, it is a single I2C operation, which does not need
a lock either case.
On top of that, this needs to be called before the call to
devm_hwmon_device_register_with_info() because otherwise the first read can
happen before the bits are set.
Guenter
> + if (err < 0)
> + return err;
> + data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
> + data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
> +
> return PTR_ERR_OR_ZERO(hwmon_dev);
> }
>
Powered by blists - more mailing lists