From: Matthew Barth <msbarth@linux.ibm.com>
To: Lei YU <mine260309@gmail.com>, Patrick Venture <venture@google.com>
Cc: Matt Spinler <mspinler@linux.vnet.ibm.com>,
OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: phosphor-hwmon funcitonal interface
Date: Tue, 15 Jan 2019 09:08:10 -0600 [thread overview]
Message-ID: <b4672b3d-92a0-b327-7717-76925519d2f0@linux.ibm.com> (raw)
In-Reply-To: <CAARXrtkYwRP63pU3o+Bn_r_NZ9K2fAQr3O-3UPZqRY7KYaL6cg@mail.gmail.com>
On 1/14/19 9:33 PM, Lei YU wrote:
>> Thoughts? (IIRC< I've mentioned this idea before, but now i'm setting
>> up some cycles to hammer it out, as I continue to implement unit-tests
>> in phosphor-hwmon)
>
> I second this proposal.
>
> Be noted that this "functional" property on sensor is not the same one on
> inventory, and from my understanding, this functional property is not being
> used by other services (yet), it's just used to check if hwmon should read the
> value for the sensor or not.
>
Actually, phosphor-fan-presence/control is using the functional property
that's currently being created where the 'fault' file exists in sysfs
for the OCCs.
> So we could re-use this property to indicate if a sensor is functional or not,
> especially useful for fans that will get reading error when it's turned off,
> e.g. the fans using Aspeed fan/pwm driver.
>
This case seems to not follow whether a fan is functional or not when
its turned off. The fan is still functional, just not powered.
> @Matt What's your idea?
>
next prev parent reply other threads:[~2019-01-15 15:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 20:31 phosphor-hwmon funcitonal interface Patrick Venture
2019-01-15 3:33 ` Lei YU
2019-01-15 15:08 ` Matthew Barth [this message]
2019-01-16 1:51 ` Lei YU
2019-01-16 20:18 ` Patrick Venture
2019-01-15 15:01 ` Matthew Barth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b4672b3d-92a0-b327-7717-76925519d2f0@linux.ibm.com \
--to=msbarth@linux.ibm.com \
--cc=mine260309@gmail.com \
--cc=mspinler@linux.vnet.ibm.com \
--cc=openbmc@lists.ozlabs.org \
--cc=venture@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.