Read FRU of host through ipmi in Entity manager.

[Ed Tanous]

On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
>
>
>
> On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k at hcl.com> wrote:
>
>     Classification: HCL Internal
>
>     Hi All,
>
>                 Thanks for your comments and suggestions.
>
>                 As suggested, we are planning to implement a new process/service like  xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
>                 Following are the advantages, if host FRU handling in entity manager repo.
>
>                 1. All the FRU information is handling in the same repo.
>                 2. Entity manager Probe can work.
>                 3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.
>                 4. Adding Fru object to dbus handling are done.
>                 5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.
>
> What will happen if user is not using fru-device from entity manager, rather choose to use phosphor-ipmi-fru. Here you are restricting user to use fru-device only.

phosphor-ipmi-fru is not compatible with IPMB Frus, as the
specification requires them to be dynamically scanned based on the
SDR.  I guess you could hardcode them, but you'd still have to have
some auxiliary "does my device exist" scanning that starts to look a
lot like entity manager/fru device.  Is the use case you present a
real one, or hypothetical?

>
>                 For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.

Please don't.  Entity-manager is dynamic, and the config should be
based on a detected entity.  Mixing the dynamic and static use cases
in this way would mean that we get to rewrite all of this when we have
to support IPMB add-in-cards, which are 99% the same, but need to be
detected instead of hardcoded.
If you want this to be relatively static, attach an exposes record to
your baseboard config that has the information you need (if your IPMB
devices are on the baseboard).

>
>                 Please share your comments if any.
>
>     Thanks,
>     Kumar.
>
>