Re: Enabling pmbus power control

[Zev Weiss <zev@bewilderbeest.net>]

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