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

[Patrick Williams]

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.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200903/1c707ee4/attachment.sig>