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.
It should just work with no additional effort as long as you define the following correctly in your JSON file: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?
* 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