openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mahesh Kurapati <mahesh.kurapati@keysight.com>
To: Ed Tanous <edtanous@google.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: RE: FruDevice/Entity Manager vs hwmon
Date: Thu, 3 Jun 2021 14:44:48 +0000	[thread overview]
Message-ID: <SA1PR17MB4593DEDFE774B6AE24058A42963C9@SA1PR17MB4593.namprd17.prod.outlook.com> (raw)
In-Reply-To: <CAH2-KxD_WvQtHVAXg6etVx1hW++QMrM9B-0qvepeUetO=_WEgQ@mail.gmail.com>

Thank you Ed, and 

Please see inline. 

Mahesh

-----Original Message-----
From: Ed Tanous <edtanous@google.com> 
Sent: Wednesday, June 2, 2021 10:27 AM
To: Mahesh Kurapati <mahesh.kurapati@keysight.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: FruDevice/Entity Manager vs hwmon

On Sat, May 29, 2021 at 12:42 PM Mahesh Kurapati <mahesh.kurapati@keysight.com> wrote:
>
> Hello,
>
>
>
> I want to define temperature sensors, fans and PSUs for our new platform.  Going through the documentation and sources,  I understand that there are two approaches.  One is to define them with the same i2c path as mentioned in the device tree as part of the hwmon configuration, and the other approach is to define a json file with appropriate probe in the entity-manager/configurations folder so that the FruDevice and Entity Manager apps detect the devices as per the probe and create the matching dbus objects, while the dbus-sensors do the instrumentation.  With entity manager approach I understand that the i2c devices are created/probed when they are detected.  My questions is we don’t need the device defined in the device tree file if I go by this approach?

Correct, although you can still include them if you like.
Entity-manager relies on the new_device sysfs interface to create devices as they're found.  In the past we've used runtime-generated device tree overlays to accomplish the same thing (something I'd like to see us get back to, but that's a different story).
[Mahesh]: Got it. Thank you. 

> I understand that this helps the dynamic detection of the FRU.  Also we have LM73, and other temp sensor TMP431c that is not defined in the FruDevice record map.

What record map are you referring to?  So far as I'm aware, those devices would exist in hwmontempsensor, not fru device.  TMP73 and TMP431c could be added if they have linux driver implementations.
[Mahesh]: I am referring to the new_device mapping described in the following link that Andrew had pointed out. 

>  Next question is do I need to add support for the LM73 tmp75MP431C and other one in the FruDevice so that it gets created properly? Can I use any existing strings/mapping for these sensors?

I'm not following.  What "mappings" are you referring to?
[Mahesh]: I am referring to the string mentioned in the "Exposes" section of the configurations/*.json file to the new_device string to be used to instantiate/bind the device with Linux kernel. 

>  This is not needed if I define the entries in the device tree, and integrate with hwmon I have everything needed.  I see that hwmon and FruDevice/Entity Manager/dbus-sensors provide similar functionality.  Can I have both of these services running at the same time on the BMC?

Hypothetically you can, but it's a bit messy, and I would recommend against it.
[Mahesh]: OK.  Thank you for the input.  I will have either the phosphor-hwmon/Entity Manager.  On our system we only have the PSUs and the fan rotors  are the FRUs.  Nothing else.  If there are no lot of FRUs, I think it is better go with the phosphor-hwmon approach to integrate the sensors.  This way I don’t have to write any new code to support the new temp sensors. 

> Will it cause any conflicts?  Please help me understand.
>
>
>
> Thank you,
>
> Mahesh

      reply	other threads:[~2021-06-03 14:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-29 19:13 FruDevice/Entity Manager vs hwmon Mahesh Kurapati
2021-05-29 21:16 ` Andrei Kartashev
2021-06-03 14:47   ` Mahesh Kurapati
2021-06-02 15:26 ` Ed Tanous
2021-06-03 14:44   ` Mahesh Kurapati [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SA1PR17MB4593DEDFE774B6AE24058A42963C9@SA1PR17MB4593.namprd17.prod.outlook.com \
    --to=mahesh.kurapati@keysight.com \
    --cc=edtanous@google.com \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).