FRU device entityId and entityInstance

James Feist james.feist at linux.intel.com
Fri Oct 18 03:17:10 AEDT 2019


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.

> 
> 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?

> }
> 
> 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.

> 
> 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?

> -- 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
> 


More information about the openbmc mailing list