devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Changhuang Liang <changhuang.liang@starfivetech.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Iwona Winiarska <iwona.winiarska@intel.com>
Cc: openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org,
	Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH v1 6/6] hwmon: (peci/dimmtemp) Add support for Granite Rapids (GNR)
Date: Sat, 12 Sep 2026 08:10:59 -0700	[thread overview]
Message-ID: <c89f582d-57fe-40d5-835b-5e5ce38daccb@roeck-us.net> (raw)
In-Reply-To: <20260903133408.110847-7-changhuang.liang@starfivetech.com>

On 9/3/26 06:34, Changhuang Liang wrote:
> Add support for Granite Rapids (GNR) platform in PECI DIMM temperature
> monitoring driver.
> 
> The GNR platform has different DIMM topology from previous generations,
> with 12 channel ranks (CHAN_RANK_MAX_ON_GNR) and 2 DIMM indexes per
> channel. Define these new constants and update CHAN_RANK_MAX to use
> the GNR value since it represents the maximum across all supported
> platforms.
> 
> I am not sure whether it differs from previous models, but on GNR,
> requests to read DIMM temperature thresholds (DIMM_TEMP_MAX/
> DIMM_TEMP_CRIT) via PECI are rejected with completion code 0x90
> (invalid request). To handle this, the read_thresholds callback is not
> defined for GNR, and the visibility logic is updated to skip exposing
> the max and crit temperature attributes when thresholds are not
> supported.
> 

Are you sure this doesn't just require different parameter conversion
when calling peci_pci_local_read() ? The translation from dimm_order
and chan_rank to the register number seems to be different for each
architecture.

> The minimum PECI revision required for GNR is 0x40.
> 
> Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> ---
>   drivers/hwmon/peci/dimmtemp.c | 36 +++++++++++++++++++++++++++++++----
>   1 file changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hwmon/peci/dimmtemp.c b/drivers/hwmon/peci/dimmtemp.c
> index bd3e8715dfec..9e98effeb928 100644
> --- a/drivers/hwmon/peci/dimmtemp.c
> +++ b/drivers/hwmon/peci/dimmtemp.c
> @@ -34,8 +34,10 @@
>   #define DIMM_IDX_MAX_ON_SPR	2
>   #define CHAN_RANK_MAX_ON_EMR	8
>   #define DIMM_IDX_MAX_ON_EMR	2
> +#define CHAN_RANK_MAX_ON_GNR	12
> +#define DIMM_IDX_MAX_ON_GNR	2
>   
> -#define CHAN_RANK_MAX		CHAN_RANK_MAX_ON_HSX
> +#define CHAN_RANK_MAX		CHAN_RANK_MAX_ON_GNR
>   #define DIMM_IDX_MAX		DIMM_IDX_MAX_ON_HSX
>   #define DIMM_NUMS_MAX		(CHAN_RANK_MAX * DIMM_IDX_MAX)
>   
> @@ -125,6 +127,9 @@ static int update_thresholds(struct peci_dimmtemp *priv, int dimm_no)
>   	if (!peci_sensor_need_update(&priv->dimm[dimm_no].thresholds.state))
>   		return 0;
>   
> +	if (!priv->gen_info->read_thresholds)
> +		return -EOPNOTSUPP;
> +

This check is unnecessary: The attributes are marked as not visible
if read_thresholds is NULL, and this code will never be called.

Thanks,
Guenter


  reply	other threads:[~2026-09-12 15:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 13:34 [PATCH v1 0/6] Add StarFive JHB100 PECI support Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 1/6] dt-bindings: peci: Add StarFive JHB100 PECI controller Changhuang Liang
2026-09-03 16:35   ` Conor Dooley
2026-09-03 13:34 ` [PATCH v1 2/6] peci: controller: Add StarFive JHB100 PECI driver Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 3/6] peci: Add support for PECI CC 0x83 retry condition Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 4/6] peci: cpu: Add Intel Granite Rapids support Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 5/6] hwmon: (peci/cputemp) Add support for Granite Rapids (GNR) Changhuang Liang
2026-09-12 14:58   ` Guenter Roeck
2026-09-12 15:13   ` Guenter Roeck
2026-09-13  3:36     ` Changhuang Liang
2026-09-03 13:34 ` [PATCH v1 6/6] hwmon: (peci/dimmtemp) " Changhuang Liang
2026-09-12 15:10   ` Guenter Roeck [this message]
2026-09-13  4:07     ` Changhuang Liang
2026-09-13  4:16       ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c89f582d-57fe-40d5-835b-5e5ce38daccb@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=changhuang.liang@starfivetech.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=iwona.winiarska@intel.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).