On Tue, Apr 16, 2024 at 02:22:16PM -0700, Tony Luck wrote:
> New CPU #defines encode vendor and family as well as model.
>
> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> ---
> drivers/hwmon/peci/cputemp.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwmon/peci/cputemp.c b/drivers/hwmon/peci/cputemp.c
> index a812c15948d9..28cec5c318d4 100644
> --- a/drivers/hwmon/peci/cputemp.c
> +++ b/drivers/hwmon/peci/cputemp.c
> @@ -11,6 +11,7 @@
> #include <linux/peci-cpu.h>
> #include <linux/units.h>
>
> +#include <asm/cpu_device_id.h>
> #include "common.h"
>
> #define CORE_NUMS_MAX 64
> @@ -361,9 +362,9 @@ static int init_core_mask(struct peci_cputemp *priv)
>
> /* Get the RESOLVED_CORES register value */
> switch (peci_dev->info.model) {
> - case INTEL_FAM6_ICELAKE_X:
> - case INTEL_FAM6_ICELAKE_D:
> - case INTEL_FAM6_SAPPHIRERAPIDS_X:
> + case VFM_MODEL(INTEL_ICELAKE_X):
> + case VFM_MODEL(INTEL_ICELAKE_D):
> + case VFM_MODEL(INTEL_SAPPHIRERAPIDS_X):
$ git describe
v6.9-rc4-31-g96fca68c4fbf
$ git grep VFM_MODEL
$
So I guess this depends on some other patch ?
That might be worth mentioning, especially since
$ git describe
next-20240416
$ git grep VFM_MODEL
$
doesn't find it either.
On top of that, it looks like
#include <asm/cpu_device_id.h>
introduces a dependency on X86 which is not currently the case.
CONFIG_PECI is typically used on BMCs. Many of those do not use
Intel CPUs. It does not seem appropriate to make support for PECI
based hardware monitoring dependent on it running on an Intel CPU.
Thanks,
Guenter
