No dbus objects for phosphor-regulators

[Shawn McCarney]

On 2/11/2022 9:42 AM, Mike Jones wrote:
> Shawn, 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 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220211/68897dd5/attachment.htm>