Read FRU of host through ipmi in Entity manager.

[Vijay Khemka]

On 9/22/20, 1:58 PM, "Ed Tanous" <ed at tanous.net> wrote:

    On Tue, Sep 22, 2020 at 1:26 PM Vijay Khemka <vijaykhemka at fb.com> wrote:
    >
    >
    >
    > On 9/22/20, 1:20 PM, "Ed Tanous" <ed at tanous.net> wrote:
    >
    >     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).
    >
    > Rather than having hardcoded config, can we can scan all available ipmb
    > devices under /dev/ipmb-* and send proper ipmb command to get fru
    > data.

    When an IPMB card is installed, who is in charge of creating the
    /dev/ipmb-* node?

It should be kernel driver.

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