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

[Guenter Roeck]

On Wed, Sep 2, 2020 at 3:07 PM Alex Qiu <xqiu at google.com> wrote:
>
> Hi James,
>
> I just tried, now I have no reading at all... I saw you marked your pull request to work in progress. I'll wait for further updates...
>
I may be missing something, but isn't that the idea ?

Thanks,
Guenter

> - Alex Qiu
>
>
> On Wed, Sep 2, 2020 at 1:31 PM Alex Qiu <xqiu at google.com> wrote:
>>
>> 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