Re: Enabling pmbus power control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux