FRU device entityId and entityInstance

[Patrick Venture]

On Thu, Oct 17, 2019 at 9:17 AM James Feist <james.feist at linux.intel.com> wrote:
>
> On 10/16/19 10:57 PM, Patrick Venture wrote:
> > Because there's no association between an entity-manager board and the
> > fru device entry, I added a new interface to the entity-manager
> > hardware profile:
> >
> > "xyz.openbmc_project.Inventory.Decorator.FruDevice": {
> >      "Bus": "$bus",
> >      "Address": "$address"
> > }
> >
> > I'm making the properties uppercase like they are with the FruDevice
> > interface so that they match  -- BUS == BUS, but they are different
> > types.  I haven't dug into the code, but interestingly these are
> > uint64_t while the FruDevice Interface's BUS is 32-bit.
>
> This is because Entity-Manager reads from json, and the native json
> types are uint64_t. I've considered using the size of the variable to
> determine this, but then guessing the type became confusing, and the
> usage of visitors went up, and in the end it didn't seem worth it.

No big deal, it's just a minor inconsistency in the lookup code.  I'll
send the patch to intel-ipmi-oem later this morning.  I have it worked
for FRUs because it's a 1:1 lookup, so trivial.

>
> >
> > This lets me, in intel-ipmi-oem go from a FruDevice entry to an
> > EntityManager board entry.  From there, I added another interface:
> >
> > "xyz.openbmc_project.Inventory.Decorator.Ipmi": {
> >      "EntityId": "0x07",
> >      "EntityInstance": 1
>
> How / when will EntityInstance increment? Should you use $index here?

In this case, it's up to the implementer.  In this case it was just an
example :)  The instance number doesn't necessarily need to be
monotonically increasing, etc, so whatever someone may end up wanting
is fine.

>
> > }
> >
> > If this interface is present, and those properties set, they are used
> > in intel-ipmi-oem.  I have a patch for this that has been tested and
> > works.  I haven't updated the schema yet, as I wanted to get a second
> > opinion on it.
>
> This looks very reasonable, and in line with current designs.

Ok.

>
> >
> > The sensors also need the Ipmi Decorators, but I just added the
> > EntityId property to the "Exposes" entries that need it, and then it's
> > in the Configuration interface.  However, I haven't yet pushed that
> > into a sensor.  I see there's an association interface on a Sensor and
> > that points back to the parent board, but it isn't immediately clear
> > to me how to then travel to the sensor from there
>
> I'm a little lost on why you need to add this to the sensor. The
> association should point back to the base configuration that caused it,
> and you're adding the EntityId to the base right? So from current logic
> you would just need to take object that contains the managedObject of
> all the sensors, looks at the associations, that should point to a base
> object in EntityManager. If that base object has a Decorator.Ipmi, then
> you can get the Entity Information.. or am I missing something?

Looking at the YAML files, I think that matches what you're
suggesting. Phew! I was a bit worried.  It was my understanding that
the entityIds might differ between a sensor on a board and the board,
but that doesn't really make sense --> and I was also worried the
entityInstance would differ --> but also, that doesn't seem to be the
case.

You're absolutely right.  Using the association to look back at the
board should work fine :)

>
> > -- by first thought
> > was path swapping, but that won't work in cases like tmp441 where one
> > sensor configuration feeds two sensors.  Anyways, I was thinking, what
> > if the Sensor creation added another interface for decoration (if
> > configured), so that intel-ipmi-oem can get the entityId and so on by
> > just grabbing the sensor object -- it'd be yet another decoration
> > interface?
> >
> > Patrick
> >