On Mon, 2021-10-11 at 22:06 +0200, Borislav Petkov wrote:

On Mon, Oct 11, 2021 at 07:21:26PM +0000, Winiarska, Iwona wrote:

quoted

Same reason why PECI can't just include arch/x86 directly (we're building
for
ARM, not x86).

Aha.

So what do you need those INTEL_FAM6* defines for?

To identify the x86 CPU and use that as a match for binding PECI drivers.

I see peci_cpu_device_ids[] which are used to match the CPU so at least
that thing must be loading on x86 hardware... reading your 0th message,
it sounds like that peci-cpu thing is loaded on an x86 CPU and it then
exposes those interfaces which a PECI controller accesses.

Everything that's part of this series runs on the BMC (Baseboard Management
Controller). There's nothing ARM specific to it - it's just that the BMC
hardware we're currently supporting is ARM-based.
PECI is an interface that's exposed by some x86 CPUs - but that's a hardware
interface (available completely independent from whatever is actually running on
the x86 CPU).

And then I see in init_core_mask() the single usage of INTEL_FAM6* and
that drivers/hwmon/peci/cputemp.c is a CPU temp monitoring client so
that thing probably runs on x86 too.

That also runs on BMC, it uses functionality offered by peci-cpu to expose hwmon
interface to userspace.
Userspace that makes use of that hwmon interface also runs on the BMC and
exposes sensor data to user (via redfish API, or web-based interface).

Or?

If it does, then you don't need the code move.

But it looks like I'm missing something...

I'm sorry - it looks that my description in the cover letter wasn't clear
enough.

Thanks
-Iwona