With this the hardcoded /sys location for reading sensor data can be
changed. In particular it makes it possible to tar up the /sys directory
when a problem is encountered, and then reproduce it on another system.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
sensors_parse_chip_name claims to overwrite all of result but path is
not set. This is generally not a problem when using statically allocated
data that is pre-zeroed but the parser uses dynamic allocation and the
chip name may contain garbage depending on the specific code flow
resulting from compiling the parser.
Setting the path was dropped when it was renamed from busname.
Fixes: 8896ba3b ("Rename sensors_chip_name.busname to path, as this is
what we are using it for by now.")
The dependencies for the parser files are not correct.
There is baroque irule adding header prerequisites to the parser but the
parser may still fail to build.
The real dependency is on conf-parse.h
There is no way to tell make that a rule produces two targets, such as
parse.c and parse.h. However, the dependency files are generated by a
separate rule, and not as a byproduct of building the source so they can
themselves have dependencies.
And dependencies they do have: when the header is generated it's in lib
but when the header is missing while generating dependency file it's
searched in top directory, and then the file that depends on it cannot
be built because the header neveer appears there.
When the generated .c file is addded as prerequisite to the dependency
file that should reference the header generated together with the .c
file the dependency file is generated correctly with the header present.
This is not easily reproducible with the current source but adding
conf-lex.h generated with conf-lex.c and including it in conf-parse.c
now makes both conf-lex.ad depend on conf-parse.h and conf-lex.ad on
conf-lex.h making the build 100% fail.
This is not really a problem when the specific scaling factors happen to
be for factors not matched by a generic match but this may not hold in
general over time.
Fixes: 1bd92120 ("Fill the magnitude field of dynamically generated device entries.")
Some SDIO drivers, namely WiFi adapter drivers, include hwmon support.
Add support for parsing the device name, so they don't get treated as
platform / virtual devices.
Signed-off-by: Chen-Yu Tsai <wenst@google.com>
Devices under the MMC / SDIO bus have a "device" entry that is not a
symbolic link; instead it contains the device ID of the SDIO device.
This causes the sysfs parsing code in libsensors to error out, as it
expects all "device" entries be symbolic links to the underlying device.
Check for non-symlink entries before calling realpath() to avoid using
it as a valid device link.
Signed-off-by: Chen-Yu Tsai <wenst@google.com>
ACPI hwmon sensor driver name has a different format such as
APMC0D29:00
APMC0D29:01
compared with DTB. This patch supports this format and gives
the correct device address as below
apm_xgene-isa-0000 => APMC0D29:00
Adapter: ISA adapter
SoC Temperature: +35.0°C
CPU power: 11.00 W
IO power: 20.00 W
apm_xgene-isa-0001 => APMC0D29:01
Adapter: ISA adapter
SoC Temperature: +33.0°C
CPU power: 13.00 W
IO power: 23.83 W
Signed-off-by: Hoan Tran <hoan@os.amperecomputing.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>
Michal Suchanek