openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Ed Tanous <edtanous@google.com>
To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: VR control from the BMC
Date: Mon, 26 Oct 2020 16:02:22 -0700	[thread overview]
Message-ID: <CAH2-KxCDtq4TDhcENWB65neeqq2QW2TDTV4e7mudaram5EcWGg@mail.gmail.com> (raw)

In the near future, I'm going to have some needs for OpenBMC to be
able to control VRs.  These VRs might be on the baseboard itself, or
on detected PCIe add-in-cards, and controlled over PMBus.
Additionally, I will need a "hardware safe" way for the host to be
able to modify the behavior of these VRs (usually different voltage
settings), and to have that interface be constrained in such a way
that the host can never set a value that's outside of a predefined
range that's known to be safe for the hardware, which the BMC will own
the definition of for security purposes.

Does anyone else have similar needs?  I've been pointed to
phosphor-regulators which has some similar parallels;  As-is, that
solution won't work for me, because it's relying on fixed, platform
specific json scripting to accomplish its goals.  My hope would be for
a more generalized linux devicetree based solution, as well as a
representation on dbus that could be modified at runtime by
Redfish/IPMI in band.

Is there any other work I should look into that's similar?  Does
anyone have any strong opinions on how this should be organized or how
it could be built?

Thanks,

-Ed

             reply	other threads:[~2020-10-26 23:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 23:02 Ed Tanous [this message]
2020-10-27 18:55 ` VR control from the BMC Vijay Khemka
2020-10-27 19:10   ` Ed Tanous
2020-10-27 20:11     ` Vijay Khemka
2020-10-27 20:26 ` Patrick Williams
2020-10-27 20:54   ` Ed Tanous

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH2-KxCDtq4TDhcENWB65neeqq2QW2TDTV4e7mudaram5EcWGg@mail.gmail.com \
    --to=edtanous@google.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).