On Mon, 2021-10-11 at 23:31 +0200, Borislav Petkov wrote: > On Mon, Oct 11, 2021 at 08:38:43PM +0000, Winiarska, Iwona wrote: > > 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). > > Aha, I think I got it: so this whole PECI pile is supposed to run on > the BMC - which can be ARM but doesn't have to be, i.e., code should be > generic enough - and the interfaces to the x86 CPU do get exposed to the > Linux running on the BMC. > > Which brings me to the answer to your other mail: > > On Mon, Oct 11, 2021 at 07:32:38PM +0000, Winiarska, Iwona wrote: > > Nothing wrong - just a trade-off between churn and keeping things tidy > > and not duplicated, similar to patch 1. And just like in patch 1, if > > you have a strong opinion against it - we can duplicate. > > So it is not about strong opinion. Rather, it is about whether this > exporting would be disadvantageous for x86 freedom. And I think it will > be: > > Because if you exported those and then we went and changed those > interfaces and defines (changed their naming, function arguments, > whatever) and something outside of x86 used them, we will break that > something. > > And usually we go and fix those users too but I doubt anyone has access > to that PECI hw to actually test fixes, etc, etc. We (OpenBMC) do have PECI HW, so that shouldn't be a problem. > So I'd prefer the small amount of duplication vs external stuff using > x86 facilities any day of the week. And so I'd suggest you simply copy > the handful of functions and defines you're gonna be needing and the > defines and be done with it. > > Dave's idea makes sense to me too but lately it keeps happening that > we change something in x86-land and it turns out something "from the > outside" is using it and it breaks, so it is a lot easier if things are > independent. Both CPUID.EAX=1 decoding and definitions in intel-family are pretty "well- defined". I understand the scenario that you're describing, but in order to break the outside user there would need to be some "logic" behind the pulled in concepts (if, for example, I would use something like X86_MATCH_* defines in PECI). Thanks -Iwona > > Thx. >
