openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Vijay Khemka <vijaykhemka@fb.com>
To: Ed Tanous <edtanous@google.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: VR control from the BMC
Date: Tue, 27 Oct 2020 18:55:48 +0000	[thread overview]
Message-ID: <E5370099-203B-4CA4-AD0E-671CD2303CE7@fb.com> (raw)
In-Reply-To: <CAH2-KxCDtq4TDhcENWB65neeqq2QW2TDTV4e7mudaram5EcWGg@mail.gmail.com>

On 10/26/20, 4:04 PM, "openbmc on behalf of Ed Tanous" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of edtanous@google.com> wrote:

    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,
 
Voltage limits can certainly be passed via DTS file to limit user
application configuration setting.

    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?

I would also like to add VR firmware upgrades as well in this.

    Thanks,

    -Ed


  reply	other threads:[~2020-10-27 18:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26 23:02 VR control from the BMC Ed Tanous
2020-10-27 18:55 ` Vijay Khemka [this message]
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=E5370099-203B-4CA4-AD0E-671CD2303CE7@fb.com \
    --to=vijaykhemka@fb.com \
    --cc=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).