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>
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>
Marvell Ethernet PHYs can contain a temperature sensor, which the kernel
exports as an HWMON device. The PHY is on an MDIO bus. Add support for
this bus types to libsensors. The sensor is then displayed by sensors(1):
socaipsbus02100000ethernet02188000mdioswitch0mdio01-mdio-1
Adapter: MDIO adapter
temp1: +54.0°C (crit = +100.0°C)
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Sparse wants forward declarations of static functions to be static as
well. For sensors_eval_expr, do that. For the error callbacks,
rearrange the code so that the forward declarations are no longer
needed.
Add support for sysfs attributes temp[1-*]_min_hyst (already
implemented by drivers adt7x10, lm77 and lm92) and
temp[1-*]_lcrit_hyst (no known users yet.)
While there is no longer a hard limit to the number of sensor of a
given type per chip, I feel a little uncomfortable having no limit at
all on the amount of memory we may try to allocate. Add an arbitrary
safety limit so that a design error or a bug in a hwmon driver can't
result into an insane memory allocation.
Make memory pre-allocation steps depend on the sensor type. Things like
voltages, temperatures or fans are typically plenty, however vid and
chassis intrusion are typically only a few, and there can only be one
beep_enable by design. This saves a small amount of temporary memory
for cheap.
max_subfeatures is computed the first time it is needed, we can do
exactly the same with FEATURE_SIZE. Introduce feature_size as a static
variable so that we don't have to recompute it again and again.
When gathering the attributes of each hwmon chip, libsensors uses a
temporary structure in memory to order and group all the attributes
into features. This temporary structure used to be a single array with
room for every possible attribute/subfeature. While simple, this
approach required to predefine a maximum number of per-type sensor
that could be handled.
In order to get rid of this arbitrary limit, which we hit and had to
raise three times already, I changed the temporary structure to an
array of dynamically allocated per-type subattribute arrays. This lets
us not allocate any memory for types which aren't implemented by a
given chip, and more importantly, this lets us reallocate room for
more attributes of a given type as needed.
I decided to allocate chunks of 8 attributes at a time, as this seemed
a good compromise between two frequent reallocations and
over-provisioning. It could be tweaked if needed.
Icing on the cake, I benchmarked this change on two different systems
and it results in performance gains. The total heap usage as reported
by valgrind is down by 50% on average, with peak memory consumption
(as reported by valgrind's massif) also down by 43% on average. The
total instructions count (as reported by valgrind's callgrind) is down
by 11% on average, with measured execution time also down by a few
percents. Valgrind rocks, BTW.
I have some ideas to optimize the memory allocations further, but I do
not expect such a huge gain from them. They may not even improve peak
memory consumption as massif shows the peak is somewhere else now at
least in some cases.
Michal Suchanek