dbus-sensors

[James Feist]

On 4/21/2020 12:35 PM, Matt Spinler wrote:
> Hi James,
> 
> We're looking into using dbus-sensors(HwmonTemp and PSU) in the future,
> but would need to make a few changes to fit our requirements.  Was 
> wondering
> what you'd think of the following:
> 
> 1. Check if a sensor has a _fault sysfs file, and if it does and it
>    is nonzero, set the Functional property on the OperationalStatus
>    interface to false (and/or maybe 6 below)
Sounds ok.

> 
> 2. After the 10 failed reads, instead of just setting the sensor to 0
>    also make a D-Bus call to create a phosphor-logging event log and set
>    the OperationalStatus sensor to false.

Sounds ok.

> 
> 3. After creating this event log, make sure not to do it again until
>    main power is cycled.

I'd rather this be until the status goes OK again.

> 
> 4. If not already supported (was unsure), be able to find an
>    _input file based on a value it has in the corresponding _label file.

PSU sensor does this, hwmontemp does it by index.
> 
> 5. We have a case where a driver isn't loaded with power off, so somehow
>    we still need the sensors to stay on D-Bus when off (and show them
>    as not available).

All sensors are on d-bus all the time, its based on the EM config.

> 
> 6. Maybe add a new property to Sensor.Value on the validity
>    of the value property, for when driver is unloaded or there is an
>    error or the sensor reading is otherwise not valid.  We could add
>   this to phosphor-hwmon at the same time.
>   (I think this was mentioned on the list before).

Yes, this is where we've used std::nan, I'm not sure if that made it to 
all sensors as it's not tested very much. I know the fans do this.

> 
> We would definitely of course work with you on the best way to
> accomplish these, and I know #6 needs more discussion on if
> this is something we want to do in OpenBMC, though I thought
> I remembered an earlier discussion where it was popular.
> 
> Thanks,
> Matt