[PATCH v2 01/15] x86/cpu: Move intel-family to arch-independent headers
From: Winiarska, Iwona <iwona.winiarska@intel.com>
Date: 2021-10-11 20:54:08
Also in:
linux-arm-kernel, linux-devicetree, linux-doc, linux-hwmon, lkml, openbmc
On Mon, 2021-10-11 at 12:40 -0700, Dave Hansen wrote:
On 10/11/21 12:21 PM, Winiarska, Iwona wrote:quoted
On Mon, 2021-10-04 at 21:03 +0200, Borislav Petkov wrote:quoted
On Tue, Aug 03, 2021 at 01:31:20PM +0200, Iwona Winiarska wrote:quoted
Baseboard management controllers (BMC) often run Linux but are usually implemented with non-X86 processors. They can use PECI to access package config space (PCS) registers on the host CPU and since some information, e.g. figuring out the core count, can be obtained using different registers on different CPU generations, they need to decode the family and model. Move the data from arch/x86/include/asm/intel-family.h into a new file include/linux/x86/intel-family.h so that it can be used by other architectures. Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Dan Williams <redacted> --- To limit tree-wide changes and help people that were expecting intel-family defines in arch/x86 to find it more easily without going through git history, we're not removing the original header completely, we're keeping it as a "stub" that includes the new one. If there is a consensus that the tree-wide option is better, we can choose this approach.Why can't the linux/ namespace header include the x86 one so that nothing changes for arch/x86/?Same reason why PECI can't just include arch/x86 directly (we're building for ARM, not x86).If you're in include/linux/x86-hacks.h, what prevents you from doing #include "../../arch/x86/include/asm/intel-family.h" ? In the end, to the compiler, it's just a file in a weird location in the tree.? I think I'd prefer one weird include to moving that file out of arch/x86.
Using relative includes in include/linux is uncommon (I can see just one usage in libfdt.h pulling stuff from scripts), so I thought I can't use it in this way (seems slightly hacky to pull stuff from outside include path). But if that would be ok, it looks like a good alternative to avoid duplication in this case. Thanks -Iwona