Re: No dbus objects for phosphor-regulators

[Mike Jones <proclivis@gmail.com>]

Sent from my iPad

> On Feb 11, 2022, at 1:20 PM, Ed Tanous <edtanous@google.com> wrote:
> 
> On Fri, Feb 11, 2022 at 8:06 AM Shawn McCarney <shawnmm@linux.ibm.com> wrote:
>> 
>> On 2/11/2022 9:42 AM, Mike Jones wrote:
>> 
>> I was mainly surprised because a conversation I had with Guenter, if I remember correctly, suggested that /dev/i2c calls from user space work with hwmon, because hwmon does not lock the i2c except when using it.
>> 
>> So I assumed that in this case, it was the polling of hwmon that was just keeping it locked enough to conflict with phosphor-regulators and then it gives up.
>> 
>> With i2c-dev, you can specify I2C_SLAVE or I2C_SLAVE_FORCE when creating the connection.  I believe I2C_SLAVE will cause communication attempts to fail if a driver is bound.  I2C_SLAVE_FORCE will still try to communicate.
>> 
>> I wanted to take the more conservative approach, because there are scenarios where interleaving communication can cause serious problems.  For example, if one PMBus regulator supports multiple rails, you have to set the PMBus PAGE register to the rail you are interested in.  Subsequent PMBus commands will affect that rail.  If phosphor-regulators and a driver are both communicating with the regulator, they may both be setting PAGE and thus their subsequent commands are going to the wrong rail.
>> 
>> 
>> I could just not use hwmon at all use phosphor-regulators for all telemetry, but this seemed like more work.
>> 
>> Sorry about that.  I think if you have already done the work of defining the regulator and a read sensors rule in your JSON file, adding a few more sensors is not much additional work though.  Let me know if you have questions.
>> 
>> Also, I will need to figure out how to connect phosphor-regulators telemetry to Redfish and the WebUI. Are there examples of how to do that?
>> 
>> It should just work with no additional effort as long as you define the following correctly in your JSON file:
>> 
>> * The "inventory_path" property of your "chassis" object needs to match a real chassis inventory item on D-Bus.
>> 
>> * The "fru" property of your regulator "device" object needs to match a real inventory item on D-Bus.  As I mentioned earlier, normally if the regulator is pluggable then this is the regulator itself.  Otherwise it is the larger hardware item that contains it, such as a motherboard.  FRU is the acronym for Field Replaceable Unit, referring to a pluggable hardware item.
>> 
>> phosphor-regulators will publish your sensors on D-Bus with the standard object paths and properties.  The two JSON properties above are used to define a "chassis" association and an "inventory_item" association on D-Bus that is used by bmcweb.  This will cause your sensors to appear in Redfish and the Web UI.
>> 
>> Thanks,
>> 
>> Shawn
> 
> This same topic is essentially being discussed in a design doc here:
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/50509

I will move my discussion to Gerrit.

Note that I work for ADI, my team supports ADM1266, ADM1278, LTC297X, LTC388X, the MAX devices in this category, and I am on the SMIF (PMBus) Board and on the PMBus Technical Committee.

> 
> I've CCed the relevant parties from that review on this thread, and I
> don't have a strong opinion what forum we use to discuss this, but we
> should ideally all be talking together on a common solution.