All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vijay Khemka <vijaykhemka@fb.com>
To: Patrick Venture <venture@google.com>
Cc: Harry Sung1 <hsung1@lenovo.com>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	Ed Tanous <ed.tanous@intel.com>
Subject: Re: [External] Re: ipmitool FRU write question
Date: Mon, 19 Aug 2019 22:26:39 +0000	[thread overview]
Message-ID: <8E191471-44DD-41F2-8E60-B39982821C85@fb.com> (raw)
In-Reply-To: <CAO=noty_n2a5nHzL7O-hDRAuuhw8Mx8CXmTc-_0izpAzMCS_EQ@mail.gmail.com>



On 8/19/19, 3:19 PM, "Patrick Venture" <venture@google.com> wrote:

    On Mon, Aug 19, 2019 at 2:55 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 8/16/19, 11:02 AM, "openbmc on behalf of Patrick Venture" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of venture@google.com> wrote:
    >
    >     On Fri, Aug 16, 2019 at 10:47 AM Harry Sung1 <hsung1@lenovo.com> wrote:
    >     >
    >     >
    >     > > On 8/15/19 6:49 AM, Harry Sung1 wrote:
    >     > > > Hi Team,
    >     > > >
    >     > > >
    >     > > >
    >     > > > Current phosphor-host-ipmid does not support fru write command, but
    >     > > > ipmi-fru-parser supports it.
    >     > > >
    >     > > > We found this fru write command only update the data to dbus
    >     > > > inventory, but doesn't sync the data back to the EEPROM.
    >     > > >
    >     > > > Does ipmi-fru-parser has any plans to implement it? I think it is more
    >     > > > make sense to sync the data to EEPROM when we do fru write.
    >     > >
    >     > > The alternative FRU daemon from entity manager, FruDevice, supports writing
    >     > > the FRU directly.
    >     > > https://github.com/openbmc/entity-manager/blob/master/src/FruDevice.cpp
    >     > >
    >     > > Happy to see this capability added to ipmi-fru-parser, but you might be able to
    >     > > model it off FruDevice.  If you want to use FruDevice as-is, you will need the
    >     > > alternative FruWrite command sets from here.
    >     > >
    >     > > https://github.com/openbmc/intel-ipmi-oem/blob/159547cdfbf1992737dcecb
    >     > > cb3888af7795f930b/src/storagecommands.cpp#L316
    >     > >
    >     > > As written, those commands change the behavior a bit, and double buffers the
    >     > > FRU write commands.  When the last Fru write is sent, the data is flushed
    >     > > through the FRU parser to ensure that it's valid, and the user isn't doing
    >     > > anything nefarious (like changing a product name or serial
    >     > > number) before it writes the EEPROM in one chunk, as quickly as it can to
    >     > > reduce the possibility of a half written EEPROM.
    >     >
    >     > Hi Ed,
    >     >
    >     > Thanks for your kindly reply! I have surveyed the entity-manager before.
    >     > But I encountered an issue when I using phosphor-inventory-manager and entity-manager at the same time.
    >     > Both of them have same method "Notify" under same interface " xyz.openbmc_project.Inventory.Manager ", but different signature.
    >
    >     https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_ipmi-2Dfru-2Dparser_-2B_22022&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=S9tC9Xf2NSLTyHJCFTl6oIO42LpdhrtnwXbH0VssCkI&s=P80VTof0T9asp-kQ4qr9mcEY1Y3mKTfVj-bztx5-3_o&e=
    >
    >     This patch addresses part of it.
    >
    >     >
    >     > phosphor-inventory-manager:
    >     > NAME                                  TYPE    SIGNATURE   RESULT/VALUE   FLAGS
    >     > xyz.openbmc_project.Inventory.Manager interface -             -             -
    >     > .Notify                               method    a{oa{sa{sv}}} -             -
    >     >
    >     > entity-manager
    >     > NAME                                  TYPE    SIGNATURE   RESULT/VALUE   FLAGS
    >     > xyz.openbmc_project.Inventory.Manager interface -         -            -
    >     > .Notify                               method    a{sa{sv}} -            -
    >     >
    >     > So when some services call the 'Notify' method failed because of getting wrong service.
    >     > Ex: https://github.com/openbmc/ipmi-fru-parser/blob/master/writefrudata.cpp#L206
    >     > Have you ever seen this issue before?
    >
    >     I've addressed part of this issue in phosphor-host-ipmid, now it no
    >     longer assumes the FRU's owner.
    >     See patches related to:
    >
    >     https://github.com/openbmc/phosphor-host-ipmid/commit/45e93cbae0aa0d0f5385d40f5685b23e18f95351
    >     https://github.com/openbmc/phosphor-host-ipmid/commit/c26cc717a4eef18fffc1ca891bb6a6015740bf9f
    >
    >     >
    >     > Should I use intel-dbus-interfaces if I want to use Frudevice (entity-manager) and write FRU command(intel-ipmi-oem)?
    >     > Or it is compatible with original dbus-interface?
    >
    >     You use both.
    > Patrick, I am not using intel-dbus-interfaces, only using dbus-sensors. What is the use of intel-dbus-interfaces?
    
    I don't use both.  I only use phosphor-dbus-interfaces.  I was just
    indicating they weren't going to interfere with each other because the
    intel-dbus-interfaces isn't used in the same way as
    phosphor-dbus-interfaces.

Okay, thanks
    
    >
    >     >
    >     > Thanks,
    >     > Harry
    >
    >
    


  reply	other threads:[~2019-08-19 22:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15 13:49 ipmitool FRU write question Harry Sung1
2019-08-15 15:24 ` Ed Tanous
2019-08-16 16:52   ` [External] " Harry Sung1
2019-08-16 17:37     ` Ed Tanous
2019-08-22 13:58       ` Harry Sung1
2019-08-16 17:55     ` Patrick Venture
2019-08-19 21:55       ` Vijay Khemka
2019-08-19 22:18         ` Patrick Venture
2019-08-19 22:26           ` Vijay Khemka [this message]
2019-08-20  2:07             ` Harry Sung1

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=8E191471-44DD-41F2-8E60-B39982821C85@fb.com \
    --to=vijaykhemka@fb.com \
    --cc=ed.tanous@intel.com \
    --cc=hsung1@lenovo.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=venture@google.com \
    /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.