dbus-sensors:hwmontemp: additional attribute proposal

Alex Qiu xqiu at google.com
Wed Aug 12 10:46:06 AEST 2020

Hi Ed,

The question was more of a general ask on whether dbus-sensors plans for
this on record. If so, individual daemon should have the config option to
ignore a device completely. Currently, I think PSUSensor has the ability,
but HwmonTempSensor does not.

The reason behind it may be complicated. One is if we can fix the PSUSensor
performance issue on time so that we can use it directly for PID control
based on VR temperatures. And then, if we can't fix it on time, what work
around can we have? Is it upstream-able or local patches? What's more, can
we have different polling rates for temperature and voltage/current/power
by using multiple daemon for the same device? Of course, ideally, we can go
for a fast feature-enriched PSUSensor to take care of everything and
deprecate HwmonTempSensor, but you know I have been talking about schedule
for multiple times with you before...


- Alex Qiu

On Tue, Aug 11, 2020 at 4:02 PM Ed Tanous <ed at tanous.net> wrote:

> On Mon, Aug 10, 2020 at 5:09 PM Alex Qiu <xqiu at google.com> wrote:
> >
> > Hi Ed and James,
> >
> > Is it acceptable for a device to be listed in both HwmonTempSensor and
> PSUSensor?
> >
> Can you lay out a little bit of info about why you would need the same
> type in both places?  My knee jerk reaction would be to say no, under
> the idea that we shouldn't be duplicating functionality and code
> between sensors, but if there are good technical reasons that amount
> to more than "one has bugs, the other doesn't" then I definitely would
> be for allowing it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200811/73179dd6/attachment.htm>

More information about the openbmc mailing list