Fwd: meta-phosphor/sensors and phosphor-power/phosphor-regulators compatibility

[Shawn McCarney]

Forgot to cc the list of this reponse

-------- Forwarded Message --------
Subject: 	Re: meta-phosphor/sensors and 
phosphor-power/phosphor-regulators compatibility
Date: 	Fri, 11 Feb 2022 09:46:09 -0600
From: 	Shawn McCarney <shawnmm at linux.ibm.com>
To: 	Mike Jones <proclivis at gmail.com>



Hi,
> I think meta-phosphor/sensors and phosphor-power/phosphor-regulators 
> interfere with each other.
>
> 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.
>
> At the time of chassis on, the i2c has traffic on the bus, from sensors.
>
> Is there a way to make these play nice?
>
Hi,

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.

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?

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.

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.

Thanks,

Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220211/c8bfd6a9/attachment-0001.htm>