scale_value is generic function for scaling values. There is a lower
resolution then json format provides for voltage and current.
The patch is calling scale_value() and showing values with higher
resolution.
For example on Xilinx ZynqMP platform:
ina226-i2c-3-41
Adapter: i2c-0-mux (chan_id 0)
in0: 2.00 mV
in1: 848.00 mV
power1: 287.50 mW
curr1: 330.00 mA
Signed-off-by: Michal Simek <monstr@monstr.eu>
Previously, if an error happened when reading the value of a subfeature,
subCnt would get incremented and a stray comma would get printed in the
following iteration, even though nothing was printed in the previous
iteration. This would produce a syntactically incorrect JSON.
This is based on a patch from the su8 user on GitHub.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Don't print a newline if no features were printed.
This is based on a patch from the su8 user on GitHub.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
SFP modules measure the transmit power of the lazer. The sensor has
expected minimum values, and alarms when these minimams are reached.
Add support to sensors to print these.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
attributes. These are defined in the standard sysfs interface for quite
some time, and at least three drivers (max6650, lm63 and applesmc)
implement them so we should support them.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6029 7894878c-1315-0410-8ee3-d5d059ff63e0
Some sensor chips report both instantaneous and average power.
Add support to display both.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6008 7894878c-1315-0410-8ee3-d5d059ff63e0
Use defines for array sizes. For alarm attributes, take into account that both
the generic alarm flag as well as individual alarm attributes may be provided
by a driver (even though that should not be the case).
Remove overflow checks from get_sensor_limit_data(), as overflows should
no longer happen.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@6006 7894878c-1315-0410-8ee3-d5d059ff63e0
This will make it easier for us to help users find out correct scaling
factors when needed. Instead of telling them to go read the raw sysfs
attributes, they can just report the output of "sensors -u -c /dev/null".
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5877 7894878c-1315-0410-8ee3-d5d059ff63e0
Automatically scale energy and power values when printing them in cooked
mode. Fixed all the warnings and warts that were brought up by Jean in
the previous thread.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@5185 7894878c-1315-0410-8ee3-d5d059ff63e0
use it to retrieve a specific subfeature by type. While it is slighly
less efficient than looping over sensors_get_all_subfeatures(), it
often makes the application code much more elegant.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4846 7894878c-1315-0410-8ee3-d5d059ff63e0
for faster main features lookup. One side effect of this change is
that subfeatures can no longer have labels nor be ignored. I do not
think that this is a problem in practice, and actually this makes a
lot of sense.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4834 7894878c-1315-0410-8ee3-d5d059ff63e0
the rest of the subfeatures. This makes the code more simple, and
prepares for current values to be subfeatures like any others (i.e.
they can be missing.)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4833 7894878c-1315-0410-8ee3-d5d059ff63e0
get the list of all main features, and one to get the list of all the
subfeatures of a given main feature. This is a more logical interface for
applications to use. The current implementation is admittedly less than
optimal, because the storage structures weren't meant for it, but this
issue can (and will) be addressed later.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0@4831 7894878c-1315-0410-8ee3-d5d059ff63e0
