On Tue, Mar 30, 2021 at 02:38:10PM CDT, Guenter Roeck wrote:
On Tue, Mar 30, 2021 at 07:02:00PM +0100, Mark Brown wrote:
On Tue, Mar 30, 2021 at 12:56:56PM -0500, Zev Weiss wrote:
> Okay, to expand a bit on the description in my initial message -- we've
> got a single chassis with multiple server boards and a single manager board
> that handles, among other things, power control for the servers.
> The manager board has one LM25066 for each attached server, which acts as
> the "power switch" for that server. There thus really isn't any driver to
> speak of for the downstream device.
This sounds like you need a driver representing those server boards (or
the slots they plug into perhaps) that represents everything about those
boards to userspace, including power switching. I don't see why you
wouldn't have a driver for that - it's a thing that physically exists
and clearly has some software control, and you'd presumably also expect
to represent some labelling about the slot as well.
Absolutely agree.
Thanks,
Guenter
Hi Guenter, Mark,
I wanted to return to this to try to explain why structuring the kernel
support for this in a way that's specific to the device behind the PMIC
seems like an awkward fit to me, and ultimately kind of artificial.
In the system I described, the manager board with the LM25066 devices is
its own little self-contained BMC system running its own Linux kernel
(though "BMC" is perhaps a slightly misleading term because there's no
host system that it manages). The PMICs are really the only relevant
connection it has to the servers it controls power for -- they have
their own dedicated local BMCs on board as well doing all the usual BMC
tasks. A hypothetical dedicated driver for this on the manager board
wouldn't have any other hardware to touch aside from the pmbus interface
of the LM25066 itself, so calling it a server board driver seems pretty
arbitrary -- and in fact the same system also has another LM25066 that
controls the power supply to the chassis cooling fans (a totally
different downstream device, but one that would be equally well-served
by the same software).
More recently, another system has entered the picture for us that might
illustrate it more starkly -- the Delta Open19 power shelf [0] supported
by a recent code release from LinkedIn [1]. This is a rackmount power
supply with fifty outputs, each independently switchable via an LM25066
attached to an on-board BMC-style management controller (though again,
no host system involved). We (Equinix Metal) are interested in porting
a modern OpenBMC to it to replace the dated, crufty,
pre-Linux-Foundation version of OpenBMC it currently runs (as found in
the linked repo). The exact nature of the devices powered by its
outputs is well outside the scope of the firmware running on that
controller (it could be any arbitrary thing that runs on 12VDC), but we
still want to be able to both (a) retrieve per-output
voltage/current/power readings as provided by the existing LM25066 hwmon
support, and (b) control the on/off state of those outputs from
userspace.
Given the array of possible use-cases, an approach of adding
power-switch functionality to the existing LM25066 support seems like
the most obvious way to support this, so I'm hoping to see if I can get
some idea of what an acceptable implementation of that might look like.
Thanks,
Zev
[0] https://www.open19.org/marketplace/delta-16kw-power-shelf/
[1] https://github.com/linkedin/o19-bmc-firmware/tree/master/meta-openbmc/meta-linkedin/meta-deltapower
