openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Winiarska, Iwona" <iwona.winiarska@intel.com>
To: "zweiss@equinix.com" <zweiss@equinix.com>
Cc: "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"bp@alien8.de" <bp@alien8.de>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	"andrew@aj.id.au" <andrew@aj.id.au>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>
Subject: Re: [PATCH 12/14] hwmon: peci: Add dimmtemp driver
Date: Fri, 30 Jul 2021 22:48:07 +0000	[thread overview]
Message-ID: <1c1a21612e6b389549eb4b50baa6931d73401896.camel@intel.com> (raw)
In-Reply-To: <20210726220858.GO8018@packtop>

On Mon, 2021-07-26 at 22:08 +0000, Zev Weiss wrote:
> On Mon, Jul 12, 2021 at 05:04:45PM CDT, Iwona Winiarska wrote:
> > Add peci-dimmtemp driver for Digital Thermal Sensor (DTS) thermal
> > readings of DIMMs that are accessible via the processor PECI interface.
> > 
> > The main use case for the driver (and PECI interface) is out-of-band
> > management, where we're able to obtain the DTS readings from an external
> > entity connected with PECI, e.g. BMC on server platforms.
> > 
> > Co-developed-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> > Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> > Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
> > Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> > ---
> > drivers/hwmon/peci/Kconfig    |  13 +
> > drivers/hwmon/peci/Makefile   |   2 +
> > drivers/hwmon/peci/dimmtemp.c | 508 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 523 insertions(+)
> > create mode 100644 drivers/hwmon/peci/dimmtemp.c
> > 
> > diff --git a/drivers/hwmon/peci/Kconfig b/drivers/hwmon/peci/Kconfig
> > index e10eed68d70a..f2d57efa508b 100644
> > --- a/drivers/hwmon/peci/Kconfig
> > +++ b/drivers/hwmon/peci/Kconfig
> > @@ -14,5 +14,18 @@ config SENSORS_PECI_CPUTEMP
> >           This driver can also be built as a module. If so, the module
> >           will be called peci-cputemp.
> > 
> > +config SENSORS_PECI_DIMMTEMP
> > +       tristate "PECI DIMM temperature monitoring client"
> > +       depends on PECI
> > +       select SENSORS_PECI
> > +       select PECI_CPU
> > +       help
> > +         If you say yes here you get support for the generic Intel PECI hwmon
> > +         driver which provides Digital Thermal Sensor (DTS) thermal readings
> > of
> > +         DIMM components that are accessible via the processor PECI
> > interface.
> > +
> > +         This driver can also be built as a module. If so, the module
> > +         will be called peci-dimmtemp.
> > +
> > config SENSORS_PECI
> >         tristate
> > diff --git a/drivers/hwmon/peci/Makefile b/drivers/hwmon/peci/Makefile
> > index e8a0ada5ab1f..191cfa0227f3 100644
> > --- a/drivers/hwmon/peci/Makefile
> > +++ b/drivers/hwmon/peci/Makefile
> > @@ -1,5 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > 
> > peci-cputemp-y := cputemp.o
> > +peci-dimmtemp-y := dimmtemp.o
> > 
> > obj-$(CONFIG_SENSORS_PECI_CPUTEMP)      += peci-cputemp.o
> > +obj-$(CONFIG_SENSORS_PECI_DIMMTEMP)    += peci-dimmtemp.o
> > diff --git a/drivers/hwmon/peci/dimmtemp.c b/drivers/hwmon/peci/dimmtemp.c
> > new file mode 100644
> > index 000000000000..2fcb8607137a
> > --- /dev/null
> > +++ b/drivers/hwmon/peci/dimmtemp.c
> > @@ -0,0 +1,508 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright (c) 2018-2021 Intel Corporation
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/bitfield.h>
> > +#include <linux/bitops.h>
> > +#include <linux/hwmon.h>
> > +#include <linux/jiffies.h>
> > +#include <linux/module.h>
> > +#include <linux/peci.h>
> > +#include <linux/peci-cpu.h>
> > +#include <linux/units.h>
> > +#include <linux/workqueue.h>
> > +#include <linux/x86/intel-family.h>
> > +
> > +#include "common.h"
> > +
> > +#define DIMM_MASK_CHECK_DELAY_JIFFIES  msecs_to_jiffies(5000)
> > +#define DIMM_MASK_CHECK_RETRY_MAX      60 /* 60 x 5 secs = 5 minutes */
> > +
> > +/* Max number of channel ranks and DIMM index per channel */
> > +#define CHAN_RANK_MAX_ON_HSX   8
> > +#define DIMM_IDX_MAX_ON_HSX    3
> > +#define CHAN_RANK_MAX_ON_BDX   4
> > +#define DIMM_IDX_MAX_ON_BDX    3
> > +#define CHAN_RANK_MAX_ON_BDXD  2
> > +#define DIMM_IDX_MAX_ON_BDXD   2
> > +#define CHAN_RANK_MAX_ON_SKX   6
> > +#define DIMM_IDX_MAX_ON_SKX    2
> > +#define CHAN_RANK_MAX_ON_ICX   8
> > +#define DIMM_IDX_MAX_ON_ICX    2
> > +#define CHAN_RANK_MAX_ON_ICXD  4
> > +#define DIMM_IDX_MAX_ON_ICXD   2
> > +
> > +#define CHAN_RANK_MAX          CHAN_RANK_MAX_ON_HSX
> > +#define DIMM_IDX_MAX           DIMM_IDX_MAX_ON_HSX
> > +#define DIMM_NUMS_MAX          (CHAN_RANK_MAX * DIMM_IDX_MAX)
> 
> Should we perhaps have a static_assert(DIMM_NUMS_MAX <= 64) so that
> check_populated_dimms() doesn't silently break if we ever have a system
> with > 64 dimms?  (Not sure how far off that might be, but doesn't seem
> *that* wildly inconceivable, anyway.)

Ack, I'll add an assert and warn in check_populated_dimms():

BUILD_BUG_ON(DIMM_NUMS_MAX > 64);
if (chan_rank_max * dimm_idx_max > DIMM_NUMS_MAX) {
        WARN_ONCE(1, "Unsupported number of DIMMs");
        return -EINVAL;
}

> 
> On a similar note, it'd be nice if there were some neat way of
> automating the maintenance of CHAN_RANK_MAX and DIMM_IDX_MAX, but I
> don't know of any great solutions for that offhand.  (Shrug.)

With the added WARN it should be easy enough to be catch it without being an
issue.

> 
> > +
> > +#define CPU_SEG_MASK           GENMASK(23, 16)
> > +#define GET_CPU_SEG(x)         (((x) & CPU_SEG_MASK) >> 16)
> > +#define CPU_BUS_MASK           GENMASK(7, 0)
> > +#define GET_CPU_BUS(x)         ((x) & CPU_BUS_MASK)
> > +
> > +#define DIMM_TEMP_MAX          GENMASK(15, 8)
> > +#define DIMM_TEMP_CRIT         GENMASK(23, 16)
> > +#define GET_TEMP_MAX(x)                (((x) & DIMM_TEMP_MAX) >> 8)
> > +#define GET_TEMP_CRIT(x)       (((x) & DIMM_TEMP_CRIT) >> 16)
> > +
> > +struct dimm_info {
> > +       int chan_rank_max;
> > +       int dimm_idx_max;
> > +       u8 min_peci_revision;
> 
> This field doesn't seem to be used for anything that I can see; is it
> really needed?

Just like in cputemp - for device sanity check.

> 
> > +};
> > +
> > +struct peci_dimmtemp {
> > +       struct peci_device *peci_dev;
> > +       struct device *dev;
> > +       const char *name;
> > +       const struct dimm_info *gen_info;
> > +       struct delayed_work detect_work;
> > +       struct peci_sensor_data temp[DIMM_NUMS_MAX];
> > +       long temp_max[DIMM_NUMS_MAX];
> > +       long temp_crit[DIMM_NUMS_MAX];
> > +       int retry_count;
> > +       char **dimmtemp_label;
> > +       DECLARE_BITMAP(dimm_mask, DIMM_NUMS_MAX);
> > +};
> > +
> > +static u8 __dimm_temp(u32 reg, int dimm_order)
> > +{
> > +       return (reg >> (dimm_order * 8)) & 0xff;
> > +}
> > +
> > +static int get_dimm_temp(struct peci_dimmtemp *priv, int dimm_no)
> > +{
> > +       int dimm_order = dimm_no % priv->gen_info->dimm_idx_max;
> > +       int chan_rank = dimm_no / priv->gen_info->dimm_idx_max;
> > +       struct peci_device *peci_dev = priv->peci_dev;
> > +       u8 cpu_seg, cpu_bus, dev, func;
> > +       u64 offset;
> > +       u32 data;
> > +       u16 reg;
> > +       int ret;
> > +
> > +       if (!peci_sensor_need_update(&priv->temp[dimm_no]))
> > +               return 0;
> > +
> > +       ret = peci_pcs_read(peci_dev, PECI_PCS_DDR_DIMM_TEMP, chan_rank,
> > &data);
> > +       if (ret)
> > +               return ret;
> > +
> > +       priv->temp[dimm_no].value = __dimm_temp(data, dimm_order) *
> > MILLIDEGREE_PER_DEGREE;
> > +
> > +       switch (peci_dev->info.model) {
> > +       case INTEL_FAM6_ICELAKE_X:
> > +       case INTEL_FAM6_ICELAKE_D:
> > +               ret = peci_ep_pci_local_read(peci_dev, 0, 13, 0, 2, 0xd4,
> > &data);
> > +               if (ret || !(data & BIT(31)))
> > +                       break; /* Use default or previous value */
> > +
> > +               ret = peci_ep_pci_local_read(peci_dev, 0, 13, 0, 2, 0xd0,
> > &data);
> > +               if (ret)
> > +                       break; /* Use default or previous value */
> > +
> > +               cpu_seg = GET_CPU_SEG(data);
> > +               cpu_bus = GET_CPU_BUS(data);
> > +
> > +               /*
> > +                * Device 26, Offset 224e0: IMC 0 channel 0 -> rank 0
> > +                * Device 26, Offset 264e0: IMC 0 channel 1 -> rank 1
> > +                * Device 27, Offset 224e0: IMC 1 channel 0 -> rank 2
> > +                * Device 27, Offset 264e0: IMC 1 channel 1 -> rank 3
> > +                * Device 28, Offset 224e0: IMC 2 channel 0 -> rank 4
> > +                * Device 28, Offset 264e0: IMC 2 channel 1 -> rank 5
> > +                * Device 29, Offset 224e0: IMC 3 channel 0 -> rank 6
> > +                * Device 29, Offset 264e0: IMC 3 channel 1 -> rank 7
> > +                */
> > +               dev = 0x1a + chan_rank / 2;
> > +               offset = 0x224e0 + dimm_order * 4;
> > +               if (chan_rank % 2)
> > +                       offset += 0x4000;
> > +
> > +               ret = peci_mmio_read(peci_dev, 0, cpu_seg, cpu_bus, dev, 0,
> > offset, &data);
> > +               if (ret)
> > +                       return ret;
> > +
> > +               priv->temp_max[dimm_no] = GET_TEMP_MAX(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +               priv->temp_crit[dimm_no] = GET_TEMP_CRIT(data) *
> > MILLIDEGREE_PER_DEGREE;
> 
> These two lines look identical in all (non-default) cases; should we
> deduplicate them by just moving them to after the switch?

I'll refactor this.

> 
> > +
> > +               break;
> > +       case INTEL_FAM6_SKYLAKE_X:
> > +               /*
> > +                * Device 10, Function 2: IMC 0 channel 0 -> rank 0
> > +                * Device 10, Function 6: IMC 0 channel 1 -> rank 1
> > +                * Device 11, Function 2: IMC 0 channel 2 -> rank 2
> > +                * Device 12, Function 2: IMC 1 channel 0 -> rank 3
> > +                * Device 12, Function 6: IMC 1 channel 1 -> rank 4
> > +                * Device 13, Function 2: IMC 1 channel 2 -> rank 5
> > +                */
> > +               dev = 10 + chan_rank / 3 * 2 + (chan_rank % 3 == 2 ? 1 : 0);
> > +               func = chan_rank % 3 == 1 ? 6 : 2;
> > +               reg = 0x120 + dimm_order * 4;
> > +
> > +               ret = peci_pci_local_read(peci_dev, 2, dev, func, reg,
> > &data);
> > +               if (ret)
> > +                       return ret;
> > +
> > +               priv->temp_max[dimm_no] = GET_TEMP_MAX(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +               priv->temp_crit[dimm_no] = GET_TEMP_CRIT(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +
> > +               break;
> > +       case INTEL_FAM6_BROADWELL_D:
> > +               /*
> > +                * Device 10, Function 2: IMC 0 channel 0 -> rank 0
> > +                * Device 10, Function 6: IMC 0 channel 1 -> rank 1
> > +                * Device 12, Function 2: IMC 1 channel 0 -> rank 2
> > +                * Device 12, Function 6: IMC 1 channel 1 -> rank 3
> > +                */
> > +               dev = 10 + chan_rank / 2 * 2;
> > +               func = (chan_rank % 2) ? 6 : 2;
> > +               reg = 0x120 + dimm_order * 4;
> > +
> > +               ret = peci_pci_local_read(peci_dev, 2, dev, func, reg,
> > &data);
> > +               if (ret)
> > +                       return ret;
> > +
> > +               priv->temp_max[dimm_no] = GET_TEMP_MAX(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +               priv->temp_crit[dimm_no] = GET_TEMP_CRIT(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +
> > +               break;
> > +       case INTEL_FAM6_HASWELL_X:
> > +       case INTEL_FAM6_BROADWELL_X:
> > +               /*
> > +                * Device 20, Function 0: IMC 0 channel 0 -> rank 0
> > +                * Device 20, Function 1: IMC 0 channel 1 -> rank 1
> > +                * Device 21, Function 0: IMC 0 channel 2 -> rank 2
> > +                * Device 21, Function 1: IMC 0 channel 3 -> rank 3
> > +                * Device 23, Function 0: IMC 1 channel 0 -> rank 4
> > +                * Device 23, Function 1: IMC 1 channel 1 -> rank 5
> > +                * Device 24, Function 0: IMC 1 channel 2 -> rank 6
> > +                * Device 24, Function 1: IMC 1 channel 3 -> rank 7
> > +                */
> > +               dev = 20 + chan_rank / 2 + chan_rank / 4;
> > +               func = chan_rank % 2;
> > +               reg = 0x120 + dimm_order * 4;
> > +
> > +               ret = peci_pci_local_read(peci_dev, 1, dev, func, reg,
> > &data);
> > +               if (ret)
> > +                       return ret;
> > +
> > +               priv->temp_max[dimm_no] = GET_TEMP_MAX(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +               priv->temp_crit[dimm_no] = GET_TEMP_CRIT(data) *
> > MILLIDEGREE_PER_DEGREE;
> > +
> > +               break;
> > +       default:
> > +               return -EOPNOTSUPP;
> > +       }
> > +
> > +       peci_sensor_mark_updated(&priv->temp[dimm_no]);
> > +
> > +       return 0;
> > +}
> > +
> > +static int dimmtemp_read_string(struct device *dev,
> > +                               enum hwmon_sensor_types type,
> > +                               u32 attr, int channel, const char **str)
> > +{
> > +       struct peci_dimmtemp *priv = dev_get_drvdata(dev);
> > +
> > +       if (attr != hwmon_temp_label)
> > +               return -EOPNOTSUPP;
> > +
> > +       *str = (const char *)priv->dimmtemp_label[channel];
> > +
> > +       return 0;
> > +}
> > +
> > +static int dimmtemp_read(struct device *dev, enum hwmon_sensor_types type,
> > +                        u32 attr, int channel, long *val)
> > +{
> > +       struct peci_dimmtemp *priv = dev_get_drvdata(dev);
> > +       int ret;
> > +
> > +       ret = get_dimm_temp(priv, channel);
> > +       if (ret)
> > +               return ret;
> > +
> > +       switch (attr) {
> > +       case hwmon_temp_input:
> > +               *val = priv->temp[channel].value;
> > +               break;
> > +       case hwmon_temp_max:
> > +               *val = priv->temp_max[channel];
> > +               break;
> > +       case hwmon_temp_crit:
> > +               *val = priv->temp_crit[channel];
> > +               break;
> > +       default:
> > +               return -EOPNOTSUPP;
> > +       }
> > +
> > +       return 0;
> > +}
> > +
> > +static umode_t dimmtemp_is_visible(const void *data, enum
> > hwmon_sensor_types type,
> > +                                  u32 attr, int channel)
> > +{
> > +       const struct peci_dimmtemp *priv = data;
> > +
> > +       if (test_bit(channel, priv->dimm_mask))
> > +               return 0444;
> > +
> > +       return 0;
> > +}
> > +
> > +static const struct hwmon_ops peci_dimmtemp_ops = {
> > +       .is_visible = dimmtemp_is_visible,
> > +       .read_string = dimmtemp_read_string,
> > +       .read = dimmtemp_read,
> > +};
> > +
> > +static int check_populated_dimms(struct peci_dimmtemp *priv)
> > +{
> > +       int chan_rank_max = priv->gen_info->chan_rank_max;
> > +       int dimm_idx_max = priv->gen_info->dimm_idx_max;
> > +       int chan_rank, dimm_idx, ret;
> > +       u64 dimm_mask = 0;
> > +       u32 pcs;
> > +
> > +       for (chan_rank = 0; chan_rank < chan_rank_max; chan_rank++) {
> > +               ret = peci_pcs_read(priv->peci_dev, PECI_PCS_DDR_DIMM_TEMP,
> > chan_rank, &pcs);
> > +               if (ret) {
> > +                       /*
> > +                        * Overall, we expect either success or -EINVAL in
> > +                        * order to determine whether DIMM is populated or
> > not.
> > +                        * For anything else - we fall back to defering the
> > +                        * detection to be performed at a later point in
> > time.
> > +                        */
> > +                       if (ret == -EINVAL)
> > +                               continue;
> > +                       else
> > +                               return -EAGAIN;
> > +               }
> > +
> > +               for (dimm_idx = 0; dimm_idx < dimm_idx_max; dimm_idx++)
> > +                       if (__dimm_temp(pcs, dimm_idx))
> > +                               dimm_mask |= BIT(chan_rank * dimm_idx_max +
> > dimm_idx);
> > +       }
> > +       /*
> > +        * It's possible that memory training is not done yet. In this case
> > we
> > +        * defer the detection to be performed at a later point in time.
> > +        */
> > +       if (!dimm_mask)
> > +               return -EAGAIN;
> > +
> > +       dev_dbg(priv->dev, "Scanned populated DIMMs: %#llx\n", dimm_mask);
> 
> Hmm, though aside from this one debug print it seems like this function
> could just as easily operate directly on priv->dimm_mask if we wanted to
> make it safe for >64 dimms (I have no particular objection to keeping it
> as-is for now though).

I'll leave it as is for now.

Thanks
-Iwona

  reply	other threads:[~2021-07-30 22:50 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-12 22:04 [PATCH 00/14] Introduce PECI subsystem Iwona Winiarska
2021-07-12 22:04 ` [PATCH 01/14] x86/cpu: Move intel-family to arch-independent headers Iwona Winiarska
2021-07-14 16:54   ` Williams, Dan J
2021-07-15 16:47     ` Winiarska, Iwona
2021-07-15 18:13       ` Dan Williams
2021-07-15 18:29         ` Luck, Tony
2021-07-12 22:04 ` [PATCH 02/14] x86/cpu: Extract cpuid helpers to arch-independent Iwona Winiarska
2021-07-14 16:58   ` Williams, Dan J
2021-07-15 16:51     ` Winiarska, Iwona
2021-07-15 16:58       ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 03/14] dt-bindings: Add generic bindings for PECI Iwona Winiarska
2021-07-12 22:04 ` [PATCH 04/14] dt-bindings: Add bindings for peci-aspeed Iwona Winiarska
2021-07-15 16:28   ` Rob Herring
2021-07-16 21:22     ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 05/14] ARM: dts: aspeed: Add PECI controller nodes Iwona Winiarska
2021-07-12 22:04 ` [PATCH 06/14] peci: Add core infrastructure Iwona Winiarska
2021-07-14 17:19   ` Williams, Dan J
2021-07-16 21:08     ` Winiarska, Iwona
2021-07-16 21:50       ` Dan Williams
2021-07-17  6:12         ` gregkh
2021-07-17 20:54           ` Dan Williams
2021-07-12 22:04 ` [PATCH 07/14] peci: Add peci-aspeed controller driver Iwona Winiarska
2021-07-13  5:02   ` Randy Dunlap
2021-07-15 16:42     ` Winiarska, Iwona
2021-07-14 17:39   ` Williams, Dan J
2021-07-16 21:17     ` Winiarska, Iwona
2021-07-27  8:49   ` Zev Weiss
2021-07-29 14:03     ` Winiarska, Iwona
2021-07-29 18:15       ` Zev Weiss
2021-07-12 22:04 ` [PATCH 08/14] peci: Add device detection Iwona Winiarska
2021-07-14 21:05   ` Williams, Dan J
2021-07-16 21:20     ` Winiarska, Iwona
2021-07-27 17:49   ` Zev Weiss
2021-07-29 18:55     ` Winiarska, Iwona
2021-07-29 20:50       ` Zev Weiss
2021-07-30 20:10         ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 09/14] peci: Add support for PECI device drivers Iwona Winiarska
2021-07-27 20:10   ` Zev Weiss
2021-07-27 21:23     ` Guenter Roeck
2021-07-29 21:17     ` Winiarska, Iwona
2021-07-29 23:22       ` Zev Weiss
2021-07-30 20:13         ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 10/14] peci: Add peci-cpu driver Iwona Winiarska
2021-07-27 11:16   ` David Müller (ELSOFT AG)
2021-07-30 20:14     ` Winiarska, Iwona
2021-07-27 21:33   ` Zev Weiss
2021-07-30 21:21     ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 11/14] hwmon: peci: Add cputemp driver Iwona Winiarska
2021-07-15 17:45   ` Guenter Roeck
2021-07-19 20:12     ` Winiarska, Iwona
2021-07-19 20:35       ` Guenter Roeck
2021-07-27  7:06   ` Zev Weiss
2021-07-30 21:51     ` Winiarska, Iwona
2021-07-30 22:04       ` Guenter Roeck
2021-07-12 22:04 ` [PATCH 12/14] hwmon: peci: Add dimmtemp driver Iwona Winiarska
2021-07-15 17:56   ` Guenter Roeck
2021-07-19 20:31     ` Winiarska, Iwona
2021-07-19 20:36       ` Guenter Roeck
2021-07-26 22:08   ` Zev Weiss
2021-07-30 22:48     ` Winiarska, Iwona [this message]
2021-07-12 22:04 ` [PATCH 13/14] docs: hwmon: Document PECI drivers Iwona Winiarska
2021-07-27 22:58   ` Zev Weiss
2021-07-28  0:49     ` Guenter Roeck
2021-08-02 11:39       ` Winiarska, Iwona
2021-08-02 11:37     ` Winiarska, Iwona
2021-08-04 17:52       ` Zev Weiss
2021-08-04 18:05         ` Guenter Roeck
2021-08-05 21:42           ` Winiarska, Iwona
2021-07-12 22:04 ` [PATCH 14/14] docs: Add PECI documentation Iwona Winiarska
2021-07-14 16:51 ` [PATCH 00/14] Introduce PECI subsystem Williams, Dan J
2021-07-15 17:33   ` Winiarska, Iwona
2021-07-15 19:34     ` Dan Williams

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=1c1a21612e6b389549eb4b50baa6931d73401896.camel@intel.com \
    --to=iwona.winiarska@intel.com \
    --cc=andrew@aj.id.au \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jae.hyun.yoo@linux.intel.com \
    --cc=jdelvare@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luto@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@redhat.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.com \
    --cc=zweiss@equinix.com \
    /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).