Re: [PATCH v1 5/6] hwmon: (peci/cputemp) Add support for Granite Rapids (GNR)
From: Winiarska, Iwona
Date: Thu Sep 17 2026 - 16:54:31 EST
On Sun, 2026-09-13 at 03:36 +0000, Changhuang Liang wrote:
> Hi, Guenter
>
> Thanks for the review.
>
> > On 9/3/26 06:34, Changhuang Liang wrote:
> > > Add Granite Rapids (GNR) CPU support to the PECI cputemp driver. The
> > > GNR platform does not support the core mask scan via PCI local read,
> > > so handle this case explicitly by returning -EPERM and skipping the
> > > core mask initialization.
> > >
> >
> > After reading the next patch of the series: Are you sure that this is the
> > case, or
> > is it possible that Granite Rapids just uses a different access mechanism to
> > provide the information ?
> >
>
> This is the information I obtained by referring to the commit below.
> Of course, it would be best if Iwona could also help verify it.
>
> https://github.com/ocp-hm-openbmc-opf-ami/linux/commit/94b4b0c83d33bec70dcc92f687c4a32e1a1e253c
It's not that it's not supported - it's just a bit more complicated.
GNR introduces a concept of domains, and to figure out the core mask, we need to
query all the domains.
With that - there are some opens on how the domain support should be
implemented. For example, we might want to consider representing domains as
separate PECI devices, which would have an impact on the device/driver model.
Thanks
-Iwona
>
> > Thanks,
> > Guenter
> >
> > > Define new cpu_info structure for GNR with minimum PECI revision 0x40
> > > and the thermal margin conversion function
> > dts_ten_dot_six_to_millidegree().
> > >
> > > Signed-off-by: Changhuang Liang <changhuang.liang@xxxxxxxxxxxxxxxx>
> > > ---
> > > drivers/hwmon/peci/cputemp.c | 20 ++++++++++++++++++++
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/drivers/hwmon/peci/cputemp.c
> > > b/drivers/hwmon/peci/cputemp.c index 457089c561b4..43e52a6db79b
> > 100644
> > > --- a/drivers/hwmon/peci/cputemp.c
> > > +++ b/drivers/hwmon/peci/cputemp.c
> > > @@ -339,6 +339,17 @@ static int init_core_mask(struct peci_cputemp
> > *priv)
> > > u32 data;
> > > int ret;
> > >
> > > + /*
> > > + * Some platforms (e.g. Granite Rapids) do not expose the
> > RESOLVED_CORES
> > > + * register over PECI - per-core temperatures are simply not
> > > available.
> > > + */
> > > + if (!reg) {
> > > + dev_dbg(priv->dev,
> > > + "resolved cores scan is not supported on vendor-
> > > family-model
> > 0x%x\n",
> > > + peci_dev->info.x86_vfm);
> > > + return -EOPNOTSUPP;
> > > + }
> > > +
> > > /* Get the RESOLVED_CORES register value */
> > > switch (peci_dev->info.x86_vfm) {
> > > case INTEL_ICELAKE_X:
> > > @@ -543,6 +554,11 @@ static const struct cpu_info cpu_emr = {
> > > .thermal_margin_to_millidegree =
> > &dts_ten_dot_six_to_millidegree,
> > > };
> > >
> > > +static const struct cpu_info cpu_gnr = {
> > > + .min_peci_revision = 0x40,
> > > + .thermal_margin_to_millidegree = &dts_ten_dot_six_to_millidegree,
> > > };
> > > +
> > > static const struct auxiliary_device_id peci_cputemp_ids[] = {
> > > {
> > > .name = "peci_cpu.cputemp.hsx",
> > > @@ -576,6 +592,10 @@ static const struct auxiliary_device_id
> > peci_cputemp_ids[] = {
> > > .name = "peci_cpu.cputemp.emr",
> > > .driver_data = (kernel_ulong_t)&cpu_emr,
> > > },
> > > + {
> > > + .name = "peci_cpu.cputemp.gnr",
> > > + .driver_data = (kernel_ulong_t)&cpu_gnr,
> > > + },
> > > { }
> > > };
> > > MODULE_DEVICE_TABLE(auxiliary, peci_cputemp_ids);
>
> Best Regards,
> Changhuang