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

[Shawn McCarney]

> So I was looking for a way to pull a block of data for the fault log, 
> but I was hoping hwmon would still work in parallel, because it is 
> used a lot.
>
There may be support in phosphor-regulators you could use, although it 
may be intended for a different use case.

Regulators may have redundant phases.  For example, an N+1 regulator has 
one redundant phase.  If a phase stops working, the regulator will still 
work but the customer has lost redundancy. So an error can be logged to 
warn the customer.

As part of logging the phase fault error, you have the option of 
capturing an arbitrary set of debug data.  This is stored in the 
resulting error log as additional data.

You could possibly use this support for your use case.  The logic to 
determine if a 'phase fault' occurred is completely defined in the JSON 
file, so it could do whatever I2C registers compares you want.  
However,  the error message would include 'phase fault' which might be 
misleading in your case.

See the following for more info:
* 
https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/phase_fault_detection.md

* 
https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/log_phase_fault.md

* 
https://github.com/openbmc/phosphor-power/blob/master/phosphor-regulators/docs/config_file/i2c_capture_bytes.md 
for more info.

> Also, min/max values are not directly supported, clearing those 
> values, etc.
>
the *_peak and *_valley sensor types are intended for max/min sensor 
values that are calculated by the regulator device itself. The regulator 
usually samples values very frequently and is more accurate than a 
firmware calculated min/max.  Currently the _peak and _valley sensors 
are cleared on each boot.  You are correct that there is not currently 
support to clear it manually.

> But, if phosphor-regulators could consume hwmon values, or some other 
> driver interface, that would have value. Currently, I have ADI 
> customers that want to switch from a PMBus Hot Swap to a I2C Hotswap 
> to get some features, and they are in pain because their software uses 
> PMBus directly via i2c. If they had used hwmon, I could have written 
> them an emulation hwmon driver and all their software would have just 
> worked. The lack of driver abstraction is making their product 
> evolution difficult. This makes me hesitate wrt using 
> phosphor-regulators.
>
I understand your concern here.  I would not claim the 
phosphor-regulators application solves all use cases or is an ideal 
design.  It provides some functionality that was mandatory on the 
systems I work on.  I was hopeful it would be useful to others, but 
there are definitely caveats.

> I will invest more time in understanding phosphor-regulators. Mainly I 
> need to know how telemetry here would get connected to Redfish and 
> WebUI, etc. Does all the telemetry you mentioned below automatically 
> get connected to these?
>
I answered this in another response.

Thanks,

Shawn