Thread (49 messages) 49 messages, 7 authors, 2021-11-16

[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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help