All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vijay Khemka <vijaykhemka@fb.com>
To: Ed Tanous <ed@tanous.net>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Chassis reset
Date: Tue, 29 Sep 2020 22:13:52 +0000	[thread overview]
Message-ID: <3C833FB0-8B23-4F0D-BA4D-60033CA2557F@fb.com> (raw)
In-Reply-To: <CACWQX831_jv3NXBEjX6mCDgne65ynASgAeNNHUpiOUfME53Swg@mail.gmail.com>



On 9/23/20, 7:24 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Wed, Sep 23, 2020 at 6:59 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >     >
    >     > I'm not understanding what you mean by "come up with an API to steer the
    >     > Redfish..."  I think everything is specified here at a dbus level.  The
    >     > issue is figuring out the appropriate Redfish model of
    >     > Chassis/ComputerSystem objects (along with the included Resource.Reset
    >     > types).  To a casual reader, who hasn't been involved much in Redfish
    >     > implementation, the current mapping of these ResetTypes seems fairly
    >     > arbitrary.
    >
    >     Some might be arbitrary, but most are explicit and chosen on purpose,
    >     especially in the case of the System schema.  The Chassis schema is a
    >     little more lax, as it's more of a backward compatibility thing today.
    >     I think you (Vijay) are the first person trying to model it
    >     "properly".
    >
    >     What I mean is that the current Redfish definition of Chassis points
    >     the PowerCycle action to chassis0.  That PowerCycle action now needs
    >     to point at multiple things, chassis0 if we don't support AC reset, or
    >     chassis_system0 if we do.  That is the "steering" I was referring to.
    >
    > How about we map powerCycle to chassis0 and ForceRestart to chassis_system0
    >
    >

    I would not be in favor of this.  Technically you're implementing a
    PowerCycle here as you're cycling the power supplies off then on.  A
    ForceReset would be if you asserted some kind of reset pin to the
    board, while keeping the power supplies up, which, while valid, is not
    what you're doing.

I am actually asserting a pin by sending i2c command to HSC (Hot swap controller)
Which removes power and restores back.

    Also, it would mean that we have multiple actions to maintain
    externally, and users would have no guarantees about which ones are
    supported.  Mapping PowerCycle to the best supported mechanism we have
    seems like the best thing to do here.

Then should we map this chassis powercycle to chassis_system0 in the code? 


  reply	other threads:[~2020-09-29 22:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 19:50 Chassis reset Vijay Khemka
2020-09-18 21:38 ` Ed Tanous
2020-09-18 23:28   ` Vijay Khemka
2020-09-19  0:17     ` Ed Tanous
2020-09-22 19:16       ` Vijay Khemka
2020-09-23  0:17         ` Ed Tanous
2020-09-23  5:45           ` Vijay Khemka
2020-09-23 19:10             ` Patrick Williams
2020-09-23 19:26               ` Ed Tanous
2020-09-23 19:55                 ` Vijay Khemka
2020-09-23 20:21                 ` Patrick Williams
2020-09-23 21:12                   ` Ed Tanous
2020-09-23 21:42                     ` Patrick Williams
2020-09-23 21:59                       ` Bills, Jason M
2020-09-23 22:35                         ` Ed Tanous
2020-09-23 23:29                           ` Bills, Jason M
2020-09-23 22:31                       ` Ed Tanous
2020-09-24  1:59                         ` Vijay Khemka
2020-09-24  2:24                           ` Ed Tanous
2020-09-29 22:13                             ` Vijay Khemka [this message]
2020-09-29 22:22                               ` Ed Tanous
2020-09-29 23:29                                 ` Vijay Khemka
2020-09-24  3:08                       ` Joseph Reynolds
2020-09-24  1:48                     ` Vijay Khemka

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=3C833FB0-8B23-4F0D-BA4D-60033CA2557F@fb.com \
    --to=vijaykhemka@fb.com \
    --cc=ed@tanous.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.