Dealing with a sensor which doesn't have valid reading until host is powered up

[Ed Tanous]

On Thu, Sep 3, 2020 at 8:38 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Wed, Sep 02, 2020 at 10:59:12AM -0700, James Feist wrote:
> > On 8/31/2020 3:08 PM, Alex Qiu wrote:
> > > Hi James,
> > >
> > > I just came through this doc (https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/overview/posix/stream_descriptor.html).
> > > Looks like that it's a terrible idea for hwmon driver to return EAGAIN
> > > for dbus-sensors. With that, I think the proper fix is also to use other
> > > errno instead in our driver, and this caveat should be probably
> > > documented somewhere.
> > >
> >
> > Hi Alex,
> >
> > I hit something similar with peci where timeouts was causing the scan loop
> > to hang. I remembered that back when we were developing ipmbbridge we hit
> > something similar with i2c, and the work around was to use the tcp socket
> > instead https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/reference/ip__tcp/socket.html
> > as it could correctly handle the errors. This worked for me for the
> > CpuSensor and is a easy to implement change that might be worth trying for
> > other sensors
> > https://gerrit.openbmc-project.xyz/c/openbmc/dbus-sensors/+/36181.
> >
> > Thanks
> >
> > James
>
> I might have missed this but what are we going to do about the
> Sensor.Value in the case when the data isn't yet available?  Is the
> sensor only going to exist when the data is available?  Do we need to
> define a specific value to indicate that a Sensor.Value isn't available?
> Now that we've moved to a `double` for Sensor.Value it seems like we
> could use NaN.

CPUSensor code that does exactly what you describe :)

https://github.com/openbmc/dbus-sensors/blob/105a19754f003956def5934612b1de86225a4bc1/src/CPUSensor.cpp#L180

dbus-sensors has done exactly this basically since its creation.  I
wonder how we'd get that more formalized in phosphor-dbus-interfaces.

>
> --
> Patrick Williams