<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Forgot to cc the list of this reponse<br>
</p>
<div class="moz-forward-container">-------- Forwarded Message
--------
<table class="moz-email-headers-table" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>Re: meta-phosphor/sensors and
phosphor-power/phosphor-regulators compatibility</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Fri, 11 Feb 2022 09:46:09 -0600</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>Shawn McCarney <a class="moz-txt-link-rfc2396E" href="mailto:shawnmm@linux.ibm.com"><shawnmm@linux.ibm.com></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td>Mike Jones <a class="moz-txt-link-rfc2396E" href="mailto:proclivis@gmail.com"><proclivis@gmail.com></a></td>
</tr>
</tbody>
</table>
<br>
<br>
Hi,<br>
<blockquote type="cite">I think meta-phosphor/sensors and
phosphor-power/phosphor-regulators interfere with each other.<br>
<br>
When I power on chassis, journalctl shows errors from
phosphor-regulators saying the device or resource is busy and
mentions the correct i2c. It stops trying after a few attempts.
Looking at the code, I see that phosphor-regulators is using
/dev/i2c.<br>
<br>
At the time of chassis on, the i2c has traffic on the bus, from
sensors.<br>
<br>
Is there a way to make these play nice?<br>
<br>
</blockquote>
Hi,<br>
<br>
If dbus-sensors requires use of a device driver, I'm not sure if
both applications can read sensors from the same regulator at the
same time. As noted in my other response, phosphor-regulators
communicates directly with the regulator via i2c-dev. That is
because most regulator drivers don't support regulator
configuration, which is one of the key functions of
phosphor-regulators.<br>
<br>
phosphor-regulators supports the following sensor types: iout,
iout_peak, iout_valley, pout, temperature, temperature_peak, vout,
vout_peak, vout_valley. Does that cover the ones you want to
read? If so, could you switch to doing all of your sensor
readings from phosphor-regulators?<br>
<br>
Otherwise, if each application is missing one or two key sensors,
perhaps dbus-sensors or phosphor-regulators could be enhanced to
provide the missing ones? I'm pretty booked right now, but
contributions are welcome.<br>
<br>
Long term, it would be ideal for phosphor-regulators to move to
driver-based communication. That would avoid this issue. I think
we would need define a new regulator device driver framework that
provided full configuration capability. It would need to support
not just PMBus configuration but use of manufacturer-specific
interfaces or registers. Last time I read about it, the Linux
framework provided only very limited configuration and was not
intended to be used by user-space applications.<br>
<br>
Thanks,<br>
<br>
Shawn<br>
<br>
</div>
</body>
</html>