Message-ID: <1523365055.11062.95.camel@kernel.crashing.org>
Date:   Tue, 10 Apr 2018 22:57:35 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Jeffery <andrew@...id.au>,
        Joel Stanley <joel.stanley@....ibm.com>,
        Jeremy Kerr <jeremy.kerr@....ibm.com>
Subject: Re: How to expose various BMC chip controls ?

On Tue, 2018-04-10 at 13:29 +0200, Arnd Bergmann wrote:

> > Any better idea ? It's a fairly simple problem, and the above solution
> > would be very little code, but I just don't want us to go down a rabbit
> > hole if some of you have religious objections to some of it :)
> 
> I think the hard part is finding the right balance: traditionally, these
> kinds of systems used ad-hoc interfaces like /dev/mem or random
> kernel interfaces to do both very generic and very non-generic
> thigns.

Right. This is always the question, and for a bunch of things we *have*
used either generic interfaces or specialized drivers. There's an open
ended issue with our mailbox driver since we don't use the mailbox
framework, which we need to resolve, but otherwise, we are keen on
using existing interfaces when one exists.

> The initial reaction you get when posting a patch that adds
> an ad-hoc interface will (should?) always be a question of "can
> this be done using a generic interface?", but that doesn't mean
> that the answer is always "yes", we just need to come up with
> ideas of how that interface would look like and figure out together
> if it's actually worth it or not.

So I listed a few examples, I think Joel and Andrew can come up with a
few mores. These things, mostly because they control host-visible
things rather than BMC-visible things tend to simply not fit in
existing interfaces.

They are also sufficiently platform *and* BMC type specific that they
wouldn't fit into some kind of generic "BMC controls" driver either I
suspect.

Basically, what we need a set of named "knobs" that the BMC userspace
code can tweak based on policies set by a given system vendor and the
interactions between their BMC implementation (including OpenBMC
variant) and their BIOS/Firmware.

> In the cases where an ad-hoc interface is needed, I can see
> two options: we can stick something in drivers/soc that exposes
> it in the least ugly way, completely specific to that particular
> SoC, or we can create a new subsystem from "random BMC
> slave-side interfaces" and have it maintained by you all (leave
> me out of the picture, except if you are looking for ideas).

I don't think there enough commonality in these things to create a "BMC
slave interface" class that is anything other than a bunch of sysfs
files.

That's why I ended up with my personal conclusion/preference of just
having the syscon "driver" for the SoC just expose a table of a dozen
or so such knobs, and use the DT to describe them to abstract a bit the
difference between SoC models/revisions and how they are wired up in a
given platform.

> In any case, I think it makes most sense to discuss new interfaces
> between the people working on the competing BMC implementations,
> mainly to see if some functionality can be abstracted in a common
> way or not.

So we have some ideas of what competing BMC *chip* vendors do since
OpenBMC people communicates with other vendors.

We know a lot less about BMC SW stacks, but those are a rat nest of
closed source & GPL stuff that doesn't get upstream (or even released
sometimes ... ahem ...). Having had access to some vendor code in the
past, I can tell you that you really don't want to look at what's going
on in there ;-)

Now, lets be clear, these is really for a few (we hope maybe a handful
or two as described in my examples) knobs that really don't fit
anywhere else. By their very nature they are very specific to a given
BMC HW implementation.

>  I believe you are already working with the Nuvoton BMC
> people, but I don't know much about the others.

Nuvoton and Aspeed own the market as far as I know these days...

>  Is the
> Emulex/Broadcom/Aspeed "Pilot" BMC series used anywhere
> that you know of? 

I don't know.

> It seems that Renesas and TI are no longer
> active in this space, and that the big server vendors are either
> not running Linux (e.g. HP) on their BMC or they have their
> own software stack on the generic third-party BMCs (e.g. Dell).
> I think Huawei also has their own BMC hardware, but no idea
> what they run on it. Do you know of any others?

Nope. That said, I don't expect much commonality for this specific
problem.

Cheers,
Ben.

>        Arnd

Powered by blists - more mailing lists