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

[Alex Qiu]

Hi James,

I think Ed has mentioned the same thing in an internal discussion. I'll
give it a try.

Anyhow, as discussed with Guenter, EAGAIN still may not be a good use of
our case here, as it's not something that a busy loop should wait for. I've
also changed the driver to return ENODATA.

Thanks!

- Alex Qiu


On Wed, Sep 2, 2020 at 10:59 AM James Feist <james.feist at linux.intel.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200902/d9a8adfd/attachment.htm>