All of lore.kernel.org
 help / color / mirror / Atom feed
* Read FRU of host through ipmi in Entity manager.
@ 2020-09-14 16:55 Kumar Thangavel
  2020-09-14 17:25 ` Thomaiyar, Richard Marian
                   ` (2 more replies)
  0 siblings, 3 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-14 16:55 UTC (permalink / raw)
  To: openbmc
  Cc: James Feist, Vernon Mauery, Jae Hyun Yoo, Velumani T-ERS,HCLTech,
	vijaykhemka, Patrick Williams, sdasari

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

Classification: HCL Internal
Hi All,

         We are working on the Platform which has multi host and the host are FRUs.  The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
         Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
         We understand that entity manager does not support ipmb based host fru.

         So, we are proposing the design to support ipmb based FRU in entity manager.
         From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
         Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.

         Please let us know your comments on this.

Thanks,
Kumar.



::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

[-- Attachment #2: Type: text/html, Size: 5644 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-14 16:55 Read FRU of host through ipmi in Entity manager Kumar Thangavel
@ 2020-09-14 17:25 ` Thomaiyar, Richard Marian
  2020-09-14 17:28 ` James Feist
  2020-09-14 17:28 ` Ed Tanous
  2 siblings, 0 replies; 17+ messages in thread
From: Thomaiyar, Richard Marian @ 2020-09-14 17:25 UTC (permalink / raw)
  To: Kumar Thangavel, openbmc
  Cc: Jae Hyun Yoo, Vernon Mauery, vijaykhemka, James Feist,
	Velumani T-ERS, HCLTech, Patrick Williams

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

Hi Kumar,

Better to expose IPMI FRU of the host read via IPMB through FRU 
Interface (i.e. say xyz.openbmc_project.IPMB.FruDevice daemon, which can 
expose all the FRU's read through the same). In this way, current 
EntityManager probe will still work. (Note: We can add the support in 
FRUDevice if it is IPMB read of raw FRU data, so that conversion code in 
FRUDevice can still be used).

Current plan (under discussion - Needs to finalize) to expose the PLDM 
FRU in separate daemon under interface 
(https://github.com/openbmc/phosphor-dbus-interfaces/tree/master/xyz/openbmc_project/Inventory/Source/PLDM) 


James, Do you see any issue with this approach / comments ?

Regards,
Richard

On 9/14/2020 10:25 PM, Kumar Thangavel wrote:
>
> Classification: *HCL Internal*
>
> Hi All,
>
>          We are working on the Platform which has multi host and the 
> host are FRUs.  The host and BMC communication is based on IPMB. We 
> have each host is connected in separate ipmb bus.
>
>          Existing Entity manager has the FRU read info from EEPROM 
> (I2C)in the form of bin file.
>          We understand that entity manager does not support ipmb based 
> host fru.
>
>          So, we are proposing the design to support ipmb based FRU in 
> entity manager.
>          From Entity manager, we will send the generic "read host fru" 
> command request to ipmbbrige to read the host FRU.
>
>          Then, store the host fru info in the bin file to process and 
> creating dbus objects in the entity manager.
>
>          Please let us know your comments on this.
>
> Thanks,
>
> Kumar.
>
> ::DISCLAIMER::
> ------------------------------------------------------------------------
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be 
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
> may contain viruses in transmission. The e mail and its contents (with 
> or without referred errors) shall therefore not attach any liability 
> on the originator or HCL or its affiliates. Views or opinions, if any, 
> presented in this email are solely those of the author and may not 
> necessarily reflect the views or opinions of HCL or its affiliates. 
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL 
> is strictly prohibited. If you have received this email in error 
> please delete it and notify the sender immediately. Before opening any 
> email and/or attachments, please check them for viruses and other defects.
> ------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 7243 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-14 16:55 Read FRU of host through ipmi in Entity manager Kumar Thangavel
  2020-09-14 17:25 ` Thomaiyar, Richard Marian
@ 2020-09-14 17:28 ` James Feist
  2020-09-14 17:28 ` Ed Tanous
  2 siblings, 0 replies; 17+ messages in thread
From: James Feist @ 2020-09-14 17:28 UTC (permalink / raw)
  To: Kumar Thangavel, openbmc
  Cc: Vernon Mauery, Jae Hyun Yoo, Velumani T-ERS,HCLTech, vijaykhemka,
	Patrick Williams, sdasari

On 9/14/2020 9:55 AM, Kumar Thangavel wrote:
> Classification: *HCL Internal*
> 
> Hi All,
> 
>           We are working on the Platform which has multi host and the 
> host are FRUs.  The host and BMC communication is based on IPMB. We have 
> each host is connected in separate ipmb bus.
> 
>           Existing Entity manager has the FRU read info from EEPROM 
> (I2C)in the form of bin file.

Small correction here, FruDevice reads the fru from the eeprom, EM just 
reacts to the d-bus objects.

>           We understand that entity manager does not support ipmb based 
> host fru.
> 
>           So, we are proposing the design to support ipmb based FRU in 
> entity manager.
>           From Entity manager, we will send the generic "read host fru" 
> command request to ipmbbrige to read the host FRU.

That would be directly out of scope for entity-manager 
https://github.com/openbmc/entity-manager#explicitly-out-of-scope 
"Entity manager shall not directly participate in the detection of 
devices". It would be better to either 1. Create a new daemon that can 
parse the frus over ipmb, and have entity-manager probe that. Or 2. 
Update Fru-Device to be able to probe over ipmb.

> 
>           Then, store the host fru info in the bin file to process and 
> creating dbus objects in the entity manager.

Why is this? If you're going this route, Fru Device already has the 
ability to read the baseboard FRU from the file system, it would not be 
hard to have some daemon place the frus in some location that FruDevice 
could then process them.

> 
>           Please let us know your comments on this.
> 
> Thanks,
> 
> Kumar.
> 
> ::DISCLAIMER::
> ------------------------------------------------------------------------
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be 
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
> may contain viruses in transmission. The e mail and its contents (with 
> or without referred errors) shall therefore not attach any liability on 
> the originator or HCL or its affiliates. Views or opinions, if any, 
> presented in this email are solely those of the author and may not 
> necessarily reflect the views or opinions of HCL or its affiliates. Any 
> form of reproduction, dissemination, copying, disclosure, modification, 
> distribution and / or publication of this message without the prior 
> written consent of authorized representative of HCL is strictly 
> prohibited. If you have received this email in error please delete it 
> and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> ------------------------------------------------------------------------

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-14 16:55 Read FRU of host through ipmi in Entity manager Kumar Thangavel
  2020-09-14 17:25 ` Thomaiyar, Richard Marian
  2020-09-14 17:28 ` James Feist
@ 2020-09-14 17:28 ` Ed Tanous
  2020-09-15 19:20   ` Vijay Khemka
  2 siblings, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-14 17:28 UTC (permalink / raw)
  To: Kumar Thangavel
  Cc: openbmc, Jae Hyun Yoo, Vernon Mauery, vijaykhemka, James Feist,
	Velumani T-ERS, HCLTech, Patrick Williams

On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
>
>
>          We are working on the Platform which has multi host and the host are FRUs.  The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
>
>          Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
>          We understand that entity manager does not support ipmb based host fru.

Minor adjustment.  FruDevice has this capability, not Entity Manager.

>
>
>
>          So, we are proposing the design to support ipmb based FRU in entity manager.
>          From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
>
>          Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.

Minor amendment again.  I'd much rather the IPMBSensor daemon simply
create the same interface that fru device does, rather than adding
IPMB logic to FruDevice.  In this way, platforms that don't have IPMB
don't need to include the feature at all.  Also, all the IO can be
managed in one place.
https://github.com/openbmc/dbus-sensors/blob/master/src/IpmbSensor.cpp
Ideally, your IPMB device would also have an SDR that details what
FRUs and sensors exist, so that the inventory can be read and posted
to DBus at startup.  If they don't then we might need a static mapping
from an EM config once the device on the other end is detected via get
device ID.


>
>
>
>          Please let us know your comments on this.
>
>
>
> Thanks,
>
> Kumar.
>
>
>
>
>
>
>
> ::DISCLAIMER::
> ________________________________
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
> ________________________________

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-14 17:28 ` Ed Tanous
@ 2020-09-15 19:20   ` Vijay Khemka
  2020-09-21 16:44       ` Kumar Thangavel
  2020-09-22  7:51     ` Andrei Kartashev
  0 siblings, 2 replies; 17+ messages in thread
From: Vijay Khemka @ 2020-09-15 19:20 UTC (permalink / raw)
  To: Ed Tanous, Kumar Thangavel
  Cc: openbmc, Jae Hyun Yoo, Vernon Mauery, James Feist,
	Velumani T-ERS, HCLTech, Patrick Williams



On 9/14/20, 10:29 AM, "Ed Tanous" <ed@tanous.net> wrote:

    On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
    >
    > Classification: HCL Internal
    >
    > Hi All,
    >
    >
    >
    >          We are working on the Platform which has multi host and the host are FRUs.  The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
    >
    >          Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
    >          We understand that entity manager does not support ipmb based host fru.

    Minor adjustment.  FruDevice has this capability, not Entity Manager.

    >
    >
    >
    >          So, we are proposing the design to support ipmb based FRU in entity manager.
    >          From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
    >
    >          Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.

    Minor amendment again.  I'd much rather the IPMBSensor daemon simply
    create the same interface that fru device does, rather than adding
    IPMB logic to FruDevice.  In this way, platforms that don't have IPMB
    don't need to include the feature at all.  Also, all the IO can be
    managed in one place.
    https://github.com/openbmc/dbus-sensors/blob/master/src/IpmbSensor.cpp
    Ideally, your IPMB device would also have an SDR that details what
    FRUs and sensors exist, so that the inventory can be read and posted
    to DBus at startup.  If they don't then we might need a static mapping
    from an EM config once the device on the other end is detected via get
    device ID.

I agree with Ed here, all ipmb related interfaces should be implemented here.


    >
    >
    >
    >          Please let us know your comments on this.
    >
    >
    >
    > Thanks,
    >
    > Kumar.
    >
    >
    >
    >
    >
    >
    >
    > ::DISCLAIMER::
    > ________________________________
    > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
    > ________________________________


^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: Read FRU of host through ipmi in Entity manager.
@ 2020-09-21 16:44       ` Kumar Thangavel
  0 siblings, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-21 16:44 UTC (permalink / raw)
  To: Vijay Khemka, Ed Tanous
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, James Feist,
	Velumani T-ERS, HCLTech, Patrick Williams

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.
            
            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 share your comments if any. 

Thanks,
Kumar.


          
             



-----Original Message-----
From: Vijay Khemka <vijaykhemka@fb.com> 
Sent: Wednesday, September 16, 2020 12:51 AM
To: Ed Tanous <ed@tanous.net>; Kumar Thangavel <thangavel.k@hcl.com>
Cc: openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

On 9/14/20, 10:29 AM, "Ed Tanous" <ed@tanous.net> wrote:

    On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
    >
    > Classification: HCL Internal
    >
    > Hi All,
    >
    >
    >
    >          We are working on the Platform which has multi host and the host are FRUs.  The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
    >
    >          Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
    >          We understand that entity manager does not support ipmb based host fru.

    Minor adjustment.  FruDevice has this capability, not Entity Manager.

    >
    >
    >
    >          So, we are proposing the design to support ipmb based FRU in entity manager.
    >          From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
    >
    >          Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.

    Minor amendment again.  I'd much rather the IPMBSensor daemon simply
    create the same interface that fru device does, rather than adding
    IPMB logic to FruDevice.  In this way, platforms that don't have IPMB
    don't need to include the feature at all.  Also, all the IO can be
    managed in one place.
    https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fdbus-sensors%2Fblob%2Fmaster%2Fsrc%2FIpmbSensor.cpp&amp;data=02%7C01%7Cthangavel.k%40hcl.com%7C2d76e1fe99cd49a9274c08d859ac7afb%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637357944630468057&amp;sdata=i2ymwqY4AN0YeMSMbJRegBy9%2Brw1agiBXxibFZYMP9c%3D&amp;reserved=0
    Ideally, your IPMB device would also have an SDR that details what
    FRUs and sensors exist, so that the inventory can be read and posted
    to DBus at startup.  If they don't then we might need a static mapping
    from an EM config once the device on the other end is detected via get
    device ID.

I agree with Ed here, all ipmb related interfaces should be implemented here.


    >
    >
    >
    >          Please let us know your comments on this.
    >
    >
    >
    > Thanks,
    >
    > Kumar.
    >
    >
    >
    >
    >
    >
    >
    > ::DISCLAIMER::
    > ________________________________
    > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
    > ________________________________


^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: Read FRU of host through ipmi in Entity manager.
@ 2020-09-21 16:44       ` Kumar Thangavel
  0 siblings, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-21 16:44 UTC (permalink / raw)
  To: Vijay Khemka, Ed Tanous
  Cc: openbmc, Jae Hyun Yoo, Vernon Mauery, James Feist,
	Velumani T-ERS,HCLTech, Patrick Williams

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.
            
            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 share your comments if any. 

Thanks,
Kumar.


          
             



-----Original Message-----
From: Vijay Khemka <vijaykhemka@fb.com> 
Sent: Wednesday, September 16, 2020 12:51 AM
To: Ed Tanous <ed@tanous.net>; Kumar Thangavel <thangavel.k@hcl.com>
Cc: openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

On 9/14/20, 10:29 AM, "Ed Tanous" <ed@tanous.net> wrote:

    On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
    >
    > Classification: HCL Internal
    >
    > Hi All,
    >
    >
    >
    >          We are working on the Platform which has multi host and the host are FRUs.  The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
    >
    >          Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
    >          We understand that entity manager does not support ipmb based host fru.

    Minor adjustment.  FruDevice has this capability, not Entity Manager.

    >
    >
    >
    >          So, we are proposing the design to support ipmb based FRU in entity manager.
    >          From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
    >
    >          Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.

    Minor amendment again.  I'd much rather the IPMBSensor daemon simply
    create the same interface that fru device does, rather than adding
    IPMB logic to FruDevice.  In this way, platforms that don't have IPMB
    don't need to include the feature at all.  Also, all the IO can be
    managed in one place.
    https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenbmc%2Fdbus-sensors%2Fblob%2Fmaster%2Fsrc%2FIpmbSensor.cpp&amp;data=02%7C01%7Cthangavel.k%40hcl.com%7C2d76e1fe99cd49a9274c08d859ac7afb%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637357944630468057&amp;sdata=i2ymwqY4AN0YeMSMbJRegBy9%2Brw1agiBXxibFZYMP9c%3D&amp;reserved=0
    Ideally, your IPMB device would also have an SDR that details what
    FRUs and sensors exist, so that the inventory can be read and posted
    to DBus at startup.  If they don't then we might need a static mapping
    from an EM config once the device on the other end is detected via get
    device ID.

I agree with Ed here, all ipmb related interfaces should be implemented here.


    >
    >
    >
    >          Please let us know your comments on this.
    >
    >
    >
    > Thanks,
    >
    > Kumar.
    >
    >
    >
    >
    >
    >
    >
    > ::DISCLAIMER::
    > ________________________________
    > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
    > ________________________________


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-15 19:20   ` Vijay Khemka
  2020-09-21 16:44       ` Kumar Thangavel
@ 2020-09-22  7:51     ` Andrei Kartashev
  2020-09-22 20:13       ` Ed Tanous
  1 sibling, 1 reply; 17+ messages in thread
From: Andrei Kartashev @ 2020-09-22  7:51 UTC (permalink / raw)
  To: openbmc


>     Minor amendment again.  I'd much rather the IPMBSensor daemon
> simply
>     create the same interface that fru device does, rather than
> adding
>     IPMB logic to FruDevice.  In this way, platforms that don't have
> IPMB
>     don't need to include the feature at all.  Also, all the IO can
> be
>     managed in one place.
>     
> https://github.com/openbmc/dbus-sensors/blob/master/src/IpmbSensor.cpp
>     Ideally, your IPMB device would also have an SDR that details
> what
>     FRUs and sensors exist, so that the inventory can be read and
> posted
>     to DBus at startup.  If they don't then we might need a static
> mapping
>     from an EM config once the device on the other end is detected
> via get
>     device ID.
> 
> I agree with Ed here, all ipmb related interfaces should be
> implemented here.
> 


I disagree here.
First of all, IPMBSensor located in dbus-sensors package and it is
suppose to handle SENSORS. FRU is not sensor, it would be big illogical
mistake to put FruDevice code there.
Then there are already number of places in OpenBMC and related projects
uses FRU and implements encoding/decoding by its own. I already spend
lot of time debugging different behaviour of FruDevice and ipmitool...
You propose to fragment FRU handling code even more and I against this.
We at least should then extract data-source independent code from
FruDevice to a kind of library to use from different daemons. But I
prefer to do opposite - extract impb i/o code to library and use it
from both IPMBSensor and FruDevice.

-- 
Best regards,
Andrei Kartashev



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-21 16:44       ` Kumar Thangavel
  (?)
@ 2020-09-22 19:57       ` Vijay Khemka
  2020-09-22 20:20         ` Ed Tanous
  -1 siblings, 1 reply; 17+ messages in thread
From: Vijay Khemka @ 2020-09-22 19:57 UTC (permalink / raw)
  To: Kumar Thangavel, Ed Tanous
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, James Feist,
	Velumani T-ERS, HCLTech, Patrick Williams



On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@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. 

                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 share your comments if any. 

    Thanks,
    Kumar.







    -----Original Message-----
    From: Vijay Khemka <vijaykhemka@fb.com> 
    Sent: Wednesday, September 16, 2020 12:51 AM
    To: Ed Tanous <ed@tanous.net>; Kumar Thangavel <thangavel.k@hcl.com>
    Cc: openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
    Subject: Re: Read FRU of host through ipmi in Entity manager.

    [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

    On 9/14/20, 10:29 AM, "Ed Tanous" <ed@tanous.net> wrote:

        On Mon, Sep 14, 2020 at 9:57 AM Kumar Thangavel <thangavel.k@hcl.com> wrote:
        >
        > Classification: HCL Internal
        >
        > Hi All,
        >
        >
        >
        >          We are working on the Platform which has multi host and the host are FRUs.  The host and BMC communication is based on IPMB. We have each host is connected in separate ipmb bus.
        >
        >          Existing Entity manager has the FRU read info from EEPROM (I2C)in the form of bin file.
        >          We understand that entity manager does not support ipmb based host fru.

        Minor adjustment.  FruDevice has this capability, not Entity Manager.

        >
        >
        >
        >          So, we are proposing the design to support ipmb based FRU in entity manager.
        >          From Entity manager, we will send the generic "read host fru" command request to ipmbbrige to read the host FRU.
        >
        >          Then, store the host fru info in the bin file to process and creating dbus objects in the entity manager.

        Minor amendment again.  I'd much rather the IPMBSensor daemon simply
        create the same interface that fru device does, rather than adding
        IPMB logic to FruDevice.  In this way, platforms that don't have IPMB
        don't need to include the feature at all.  Also, all the IO can be
        managed in one place.
        https://urldefense.proofpoint.com/v2/url?u=https-3A__apc01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fopenbmc-252Fdbus-2Dsensors-252Fblob-252Fmaster-252Fsrc-252FIpmbSensor.cpp-26amp-3Bdata-3D02-257C01-257Cthangavel.k-2540hcl.com-257C2d76e1fe99cd49a9274c08d859ac7afb-257C189de737c93a4f5a8b686f4ca9941912-257C0-257C0-257C637357944630468057-26amp-3Bsdata-3Di2ymwqY4AN0YeMSMbJRegBy9-252Brw1agiBXxibFZYMP9c-253D-26amp-3Breserved-3D0&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=QVSWlu-mEtG6Sld0NeYhXvAUcpOxV6bVkSNsllKLkqA&s=CXdKjUg6ATp5JXX8Ou-blnmgJDzUPOP3ai9na2yT7T0&e= 
        Ideally, your IPMB device would also have an SDR that details what
        FRUs and sensors exist, so that the inventory can be read and posted
        to DBus at startup.  If they don't then we might need a static mapping
        from an EM config once the device on the other end is detected via get
        device ID.

    I agree with Ed here, all ipmb related interfaces should be implemented here.


        >
        >
        >
        >          Please let us know your comments on this.
        >
        >
        >
        > Thanks,
        >
        > Kumar.
        >
        >
        >
        >
        >
        >
        >
        > ::DISCLAIMER::
        > ________________________________
        > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
        > ________________________________



^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-21 16:44       ` Kumar Thangavel
  (?)
  (?)
@ 2020-09-22 20:04       ` Ed Tanous
  2020-09-24 15:12         ` Kumar Thangavel
  -1 siblings, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:04 UTC (permalink / raw)
  To: Kumar Thangavel
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Patrick Williams,
	James Feist, Velumani T-ERS, HCLTech, Vijay Khemka

On Mon, Sep 21, 2020 at 9:44 AM Kumar Thangavel <thangavel.k@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.

But IPMB information is bifurcated in your plan.  Ideally, Fru-Device
wouldn't even be in the entity-manager repo, it's there now just as an
artifact of the history of how it was built.

>             2. Entity manager Probe can work.

I'm not understanding this;  Entity manager probes can work regardless
of where the code is checked in.

>             3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.

This is a valid point.  Maybe some of the functions need abstracted
out into their own libraries?


>             4. Adding Fru object to dbus handling are done.

I'm not following this point.  Are you saying that code wouldn't need
duplicated?

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

See previous point about "maybe we need a library".

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


It should be noted, there's going to need to be significantly more
code added to be able to scan and parse the SDR.  I'm assuming that
code alone will be larger than FruDevice is today.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-22  7:51     ` Andrei Kartashev
@ 2020-09-22 20:13       ` Ed Tanous
  0 siblings, 0 replies; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:13 UTC (permalink / raw)
  To: Andrei Kartashev; +Cc: OpenBMC Maillist

On Tue, Sep 22, 2020 at 12:52 AM Andrei Kartashev <a.kartashev@yadro.com> wrote:
>
>
> >     Minor amendment again.  I'd much rather the IPMBSensor daemon
> > simply
> >     create the same interface that fru device does, rather than
> > adding
> >     IPMB logic to FruDevice.  In this way, platforms that don't have
> > IPMB
> >     don't need to include the feature at all.  Also, all the IO can
> > be
> >     managed in one place.
> >
> > https://github.com/openbmc/dbus-sensors/blob/master/src/IpmbSensor.cpp
> >     Ideally, your IPMB device would also have an SDR that details
> > what
> >     FRUs and sensors exist, so that the inventory can be read and
> > posted
> >     to DBus at startup.  If they don't then we might need a static
> > mapping
> >     from an EM config once the device on the other end is detected
> > via get
> >     device ID.
> >
> > I agree with Ed here, all ipmb related interfaces should be
> > implemented here.
> >
>
>
> I disagree here.
> First of all, IPMBSensor located in dbus-sensors package and it is
> suppose to handle SENSORS.
> FRU is not sensor, it would be big illogical
> mistake to put FruDevice code there.

WIth respect, dbus-sensors is a repo that's not aptly named these
days.  Ideally when this first started we would've called it
dbus-entities, but alas, that's history, and unlikely that we'll
change it (although I'd support you if you wanted to propose that).
There should be no expectation that dbus-sensors contains only
sensors, nor that dbus-sensors is the only place a sensor can be put
to dbus from, neither of which are true in the codebase today.

> Then there are already number of places in OpenBMC and related projects
> uses FRU and implements encoding/decoding by its own. I already spend
> lot of time debugging different behaviour of FruDevice and ipmitool...
> You propose to fragment FRU handling code even more and I against this.

Lets centralize the logic in a library, and move the other
implementations over to it.  Then we have a single source of FRU
parsing that all can use.  This is likely to be a problem in another
spot now that NVMe has adopted IPMI for their VPD format, we'll need
to duplicate the logic there as well, so we'd be solving future
problems (hopefully).

> We at least should then extract data-source independent code from
> FruDevice to a kind of library to use from different daemons. But I
> prefer to do opposite - extract impb i/o code to library and use it
> from both IPMBSensor and FruDevice.

My issue with that is that we're birfurcating the control of the IPMB
device in multiple places.  The easiest example of a problem this
causes is an IPMB device that needs the sensors to stop scanning while
it's doing a firmware update.  Having the control of the device
centralized in a single process like that avoids cluttering dbus, and
makes it more likely that IPMB code can be reused between the
use-cases.

Also, keep in mind that IPMBSensor is far from done, nor what I'd
really like to see.  In the next few years, I very much expect that it
will need to parse the SDR as well to automatically populate sensors.
Doing that in 2 places (FRUDevice and IPMBSensor) is inefficient, when
they could simply share the SDR parsing code in a single place.

>
> --
> Best regards,
> Andrei Kartashev
>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-22 19:57       ` Vijay Khemka
@ 2020-09-22 20:20         ` Ed Tanous
  2020-09-22 20:26           ` Vijay Khemka
  0 siblings, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:20 UTC (permalink / raw)
  To: Vijay Khemka
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
	James Feist, Velumani T-ERS, HCLTech, Patrick Williams

On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@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.
>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-22 20:20         ` Ed Tanous
@ 2020-09-22 20:26           ` Vijay Khemka
  2020-09-22 20:56             ` Ed Tanous
  2020-09-24 15:12             ` Kumar Thangavel
  0 siblings, 2 replies; 17+ messages in thread
From: Vijay Khemka @ 2020-09-22 20:26 UTC (permalink / raw)
  To: Ed Tanous
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
	James Feist, Velumani T-ERS, HCLTech, Patrick Williams



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

    On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@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.

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


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-22 20:26           ` Vijay Khemka
@ 2020-09-22 20:56             ` Ed Tanous
  2020-09-23  5:42               ` Vijay Khemka
  2020-09-24 15:12             ` Kumar Thangavel
  1 sibling, 1 reply; 17+ messages in thread
From: Ed Tanous @ 2020-09-22 20:56 UTC (permalink / raw)
  To: Vijay Khemka
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
	James Feist, Velumani T-ERS, HCLTech, Patrick Williams

On Tue, Sep 22, 2020 at 1:26 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/22/20, 1:20 PM, "Ed Tanous" <ed@tanous.net> wrote:
>
>     On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>     >
>     >
>     >
>     > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@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?

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Read FRU of host through ipmi in Entity manager.
  2020-09-22 20:56             ` Ed Tanous
@ 2020-09-23  5:42               ` Vijay Khemka
  0 siblings, 0 replies; 17+ messages in thread
From: Vijay Khemka @ 2020-09-23  5:42 UTC (permalink / raw)
  To: Ed Tanous
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Kumar Thangavel,
	James Feist, Velumani T-ERS, HCLTech, Patrick Williams



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

    On Tue, Sep 22, 2020 at 1:26 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 9/22/20, 1:20 PM, "Ed Tanous" <ed@tanous.net> wrote:
    >
    >     On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >     >
    >     >
    >     >
    >     > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@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.
    >     >
    >     >
    >


^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: Read FRU of host through ipmi in Entity manager.
  2020-09-22 20:26           ` Vijay Khemka
  2020-09-22 20:56             ` Ed Tanous
@ 2020-09-24 15:12             ` Kumar Thangavel
  1 sibling, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-24 15:12 UTC (permalink / raw)
  To: Vijay Khemka, Ed Tanous
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, James Feist,
	Velumani T-ERS, HCLTech, Patrick Williams

Classification: HCL Internal

Hi Ed/Vijay.

Thanks for your comments. Please find my response below.

-----Original Message-----
From: Vijay Khemka <vijaykhemka@fb.com>
Sent: Wednesday, September 23, 2020 1:57 AM
To: Ed Tanous <ed@tanous.net>
Cc: Kumar Thangavel <thangavel.k@hcl.com>; openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

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

    On Tue, Sep 22, 2020 at 12:57 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 9/21/20, 9:45 AM, "Kumar Thangavel" <thangavel.k@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.

Will explore more on phosphor-ipmi-fru.

    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.

Yes. Planning to have dynamic config. All the ipmb transactions are handled in Ipmbbridge. So we are getting the ipmb bus details from json file(ipmb-channels.json) and then we will do a scan in all the buses defined in json .  We will use ipmb command (ReadFruInfo) to get whether this bus/device has valid fru.


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

::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

^ permalink raw reply	[flat|nested] 17+ messages in thread

* RE: Read FRU of host through ipmi in Entity manager.
  2020-09-22 20:04       ` Ed Tanous
@ 2020-09-24 15:12         ` Kumar Thangavel
  0 siblings, 0 replies; 17+ messages in thread
From: Kumar Thangavel @ 2020-09-24 15:12 UTC (permalink / raw)
  To: Ed Tanous
  Cc: Jae Hyun Yoo, Vernon Mauery, openbmc, Patrick Williams,
	James Feist, Velumani T-ERS, HCLTech, Vijay Khemka

Classification: HCL Internal

Hi Ed,

     Thanks for your comments on this.

Thanks,
Kumar.

-----Original Message-----
From: Ed Tanous <ed@tanous.net>
Sent: Wednesday, September 23, 2020 1:34 AM
To: Kumar Thangavel <thangavel.k@hcl.com>
Cc: Vijay Khemka <vijaykhemka@fb.com>; openbmc@lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>; Vernon Mauery <vernon.mauery@linux.intel.com>; James Feist <james.feist@linux.intel.com>; Velumani T-ERS,HCLTech <velumanit@hcl.com>; Patrick Williams <patrickw3@fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

On Mon, Sep 21, 2020 at 9:44 AM Kumar Thangavel <thangavel.k@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.

But IPMB information is bifurcated in your plan.  Ideally, Fru-Device wouldn't even be in the entity-manager repo, it's there now just as an artifact of the history of how it was built.
Ok.

>             2. Entity manager Probe can work.

I'm not understanding this;  Entity manager probes can work regardless of where the code is checked in.

Ok.

>             3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.

This is a valid point.  Maybe some of the functions need abstracted out into their own libraries?

Ok.

>             4. Adding Fru object to dbus handling are done.

I'm not following this point.  Are you saying that code wouldn't need duplicated?

Yes.  Planning to reuse the functions for adding fru object to dbus handling.

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

See previous point about "maybe we need a library".

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


It should be noted, there's going to need to be significantly more code added to be able to scan and parse the SDR.  I'm assuming that code alone will be larger than FruDevice is today.
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2020-09-24 15:17 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-14 16:55 Read FRU of host through ipmi in Entity manager Kumar Thangavel
2020-09-14 17:25 ` Thomaiyar, Richard Marian
2020-09-14 17:28 ` James Feist
2020-09-14 17:28 ` Ed Tanous
2020-09-15 19:20   ` Vijay Khemka
2020-09-21 16:44     ` Kumar Thangavel
2020-09-21 16:44       ` Kumar Thangavel
2020-09-22 19:57       ` Vijay Khemka
2020-09-22 20:20         ` Ed Tanous
2020-09-22 20:26           ` Vijay Khemka
2020-09-22 20:56             ` Ed Tanous
2020-09-23  5:42               ` Vijay Khemka
2020-09-24 15:12             ` Kumar Thangavel
2020-09-22 20:04       ` Ed Tanous
2020-09-24 15:12         ` Kumar Thangavel
2020-09-22  7:51     ` Andrei Kartashev
2020-09-22 20:13       ` Ed Tanous

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.