All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Feist <james.feist@linux.intel.com>
To: Brad Bishop <bradleyb@fuzziesquirrel.com>,
	Deepak Kodihalli <dkodihal@linux.vnet.ibm.com>,
	"Thomaiyar,
	Richard Marian" <richard.marian.thomaiyar@linux.intel.com>,
	"Bhat, Sumanth" <sumanth.bhat@intel.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Processing PLDM FRU information with entity manager
Date: Wed, 20 May 2020 09:56:50 -0700	[thread overview]
Message-ID: <8e62ac67-8415-d5ef-a034-a306ae2a18c6@linux.intel.com> (raw)
In-Reply-To: <6bd3254af95cbd8ae44151f62114acca9d221962.camel@fuzziesquirrel.com>

On 5/20/2020 9:28 AM, Brad Bishop wrote:
> On Tue, 2020-05-19 at 09:10 +0530, Deepak Kodihalli wrote:
> 
> Hi Deepak
> 
>> I see there is provision for persistence, but it looks like
>> applying the persisted information works only if "D-Bus probes"
>> succeed.

There is a PowerState parameter that tells when it can be detected that 
can be used. PowerState="On" things only get removed if detected once 
power is back online.

> 
> This prompted me to take a closer look - as far as I can tell
> system.json is for debugging purposes only.  Maybe James could confirm.

No, the modifiable things are persisted there. Such as thresholds.

> 
> Given this we should probably have an application layer other than
> entity-manager layer be responsible for maintaining the PLDM FRU
> objects on the DBus at the correct time.
> 
>> the BMC will no longer have the raw PLDM FRU information on D-Bus
> 
> I think we have to fix this.  It doesn't feel right that the PLDM FRU
> DBus objects come and go off the bus as the system is powered on/off.
> 
>> How are hierarchical relationships between FRUs supposed to be
>> represented? Is that based on D-Bus pathnames? Or making use of
>> something like the D-Bus Associations interface? Any thoughts on how
>> representing such parent-child relation can be achieved via entity
>> manager configs?
> 
> I'm also hoping James or Richard will let us know what their thoughts
> are for doing this.

I need a better example. FRUs are independent things, so there is no 
hierarchy. Are you talking about Chassis level things? Those are just 
handled by having the right type.

> 
> -brad
> 

  reply	other threads:[~2020-05-20 16:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  3:40 Processing PLDM FRU information with entity manager Deepak Kodihalli
2020-05-20 16:28 ` Brad Bishop
2020-05-20 16:56   ` James Feist [this message]
2020-05-20 17:35     ` Brad Bishop
2020-05-20 17:46       ` James Feist
2020-05-26 12:56 ` D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager) Deepak Kodihalli
2020-05-27 13:50   ` D-Bus interface to provide data to entity manager Thomaiyar, Richard Marian
2020-05-27 13:58     ` Deepak Kodihalli
2020-05-27 15:25       ` Thomaiyar, Richard Marian
2020-05-27 15:46         ` Deepak Kodihalli
2020-05-27 17:19           ` Thomaiyar, Richard Marian
2020-05-28 12:09             ` Patrick Williams
2020-05-28 12:03   ` D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager) Patrick Williams
2020-05-28 12:24     ` D-Bus interface to provide data to entity manager Deepak Kodihalli
2020-05-28 16:42       ` Thomaiyar, Richard Marian
2020-05-28 18:05         ` Patrick Williams
2020-05-28 18:31           ` James Feist
2020-05-29  5:11             ` Deepak Kodihalli
2020-05-29  5:09           ` Deepak Kodihalli
2020-05-29  7:17             ` Thomaiyar, Richard Marian
2020-05-29  7:31               ` Deepak Kodihalli
2020-05-29  9:03                 ` Thomaiyar, Richard Marian
2020-05-29 10:19                   ` Deepak Kodihalli
2020-05-29 10:30                     ` Deepak Kodihalli
2020-05-29 10:33                       ` Thomaiyar, Richard Marian
2020-05-28 15:43     ` D-Bus interface to provide data to entity manager (was: Processing PLDM FRU information with entity manager) Brad Bishop
2020-05-28 18:21       ` D-Bus interface to provide data to entity manager James Feist

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=8e62ac67-8415-d5ef-a034-a306ae2a18c6@linux.intel.com \
    --to=james.feist@linux.intel.com \
    --cc=bradleyb@fuzziesquirrel.com \
    --cc=dkodihal@linux.vnet.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=richard.marian.thomaiyar@linux.intel.com \
    --cc=sumanth.bhat@intel.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.