To better support cross-compilation, the Makefile should detect the
compiler's target architecture instead of using `uname -m`, which
returns the host architecture. This approach uses the `gcc`/`clang`
compatible `-dumpmachine` option.
Cross-compilation worked but because of this bug, `isadump` and
`isaset` x86 ISA specific tools were built for PCC and ARM.
This run-time issue became a compile-time issue when `glibc` 2.30
removed the `sys/io.h` I/O port functions on ARM.
Also renamed `MACHINE` to `ARCH` to match cross-compiler conventions
for specifying the target architecture. For example,
`make ARCH=arm CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar`
Fixes#190
Signed-off-by: Lucas Magasweran <lucas.magasweran@ieee.org>
Reported-and-tested-by: Millhouse <milhouse@libreelec.tv>
Reorder Nuvoton chips in the superio_ids_winbond array to match the
order in the kernel to make lookup easier. No functional change.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Since mainline commit 0599682b826ff7bbf, the nct6775 driver uses a
0xfff8 mask when scanning for devices. Update our detection to match
the kernel.
Fixes#188
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
According to:
"Quad-Core Intel® Xeon(R) Processor 5400 Series Electrical Specifications"
(table 2-12), FSB termination voltage of the CPUs (VTT) is 1.1V +/-5%.
Initial configuration set it to 1.2V - fix that.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
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>
Add configuration for Supermicro X7DCL motherboard.
Based on slightly modified setup of X7DBE from this repo.
Runtime tested on X7DCL-3 rev. 1.1a
So far there is only support for onboard sensors,
no support for PSU failure yet, nor external PMBus sensors.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
My understanding is that SENSORS_API_VERSION should be the same
as $(LIBMAINVER)$(LIBMINORVER) in lib/Module.mk. This means that
the first digit of SENSORS_API_VERSION needs to be incremented whenever
API *or* ABI changes, because we have to increment LIBMAINVER even if
only ABI changes to avoid program breakage.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Currently only hwmon devices that don't have a parent device are treated
as virtual. Let's extend the concept to hwmon devices, that don't have
a *recognized ancestor* device (hwmon devices that according to the kernel
don't reside on a bus that we recognize). This change is meant to address
cases where a hwmon device has a thermal class device for a parent, but
the thermal class device doesn't have a parent device.
These kind of hwmon devices started appearing in the 4.19 kernel
due to commit f6b6b52ef7a54160c0. It was not reported as a kernel
regression and fixed in the kernel, because according to
Documentation/admin-guide/sysfs-rules.rst, the change was OK to make
(it says "Position of devices along device chain can change").
Fixes#139
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Go through all ancestor devices of a hwmon device until we find a device
that resides on a bus that we recognize. This change is meant to address
hwmon devices that don't reside directly on a bus, but have another
device in the middle of the hiearchy. For example:
ACPI device -> thermal device -> hwmon device
These kind of hwmon devices started appearing in the 4.19 kernel
due to commit f6b6b52ef7a54160c0. It was not reported as a kernel
regression and fixed in the kernel, because according to
Documentation/admin-guide/sysfs-rules.rst, the change was OK to make
(it says "Position of devices along device chain can change").
Fixes#133
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
According to Documentation/admin-guide/sysfs-rules.rst, the "device"
link "must never appear in any path as an element". This patch makes
lm_sensors respect that.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Rename a local variable to make it consistent with other parts of the
code. The variable is called (more descriptively) "dev_name"
in sensors_read_one_sysfs_chip(), so let's rename it to that.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Refactor bus type identification into a separate function in order to
make the code more readable and easier to maintain.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Refactor device classification into a separate function in order to
make the code more readable and easier to maintain.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The script is meant to identify the driver and kernel module responsible
for exporting a given hardware monitoring chip.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Samuel FORESTIER