lkml.org 
[lkml]   [2021]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Enabling pmbus power control
    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

    \
     
     \ /
      Last update: 2021-04-20 03:31    [W:4.608 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site