<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2/11/2022 9:42 AM, Mike Jones wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DCAD9B4C-D047-40A0-B4AD-1D21C0CF6197@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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.
<div class=""><br class="">
</div>
<div class="">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.</div>
</blockquote>
<p>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.</p>
<p>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.</p>
<blockquote type="cite"
cite="mid:DCAD9B4C-D047-40A0-B4AD-1D21C0CF6197@gmail.com">
<div class=""><br class="">
</div>
<div class="">I could just not use hwmon at all use
phosphor-regulators for all telemetry, but this seemed like more
work.</div>
<div class=""><br class="">
</div>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:DCAD9B4C-D047-40A0-B4AD-1D21C0CF6197@gmail.com">
<div class="">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?</div>
</blockquote>
It should just work with no additional effort as long as you define
the following correctly in your JSON file:<br>
<p>* The "inventory_path" property of your "chassis" object needs to
match a real chassis inventory item on D-Bus.</p>
<p>* 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.<br>
</p>
<p>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.</p>
<p>Thanks,</p>
<p>Shawn<br>
</p>
</body>
</html>