We already skip EDID addresses (0x50-0x57) by default on graphics card
I2C/DDC buses. Also skip 0x37 (DDC/CI) and 0x4f which was recently
reported as corrupting a laptop's display when probed.
This closes ticket #2392.
http://www.lm-sensors.org/ticket/2392
On recent kernels, the i2c bus may not be an immediate child of the
graphics device, instead there can be a drm class device in between.
Treat all drm class devices as graphics devices so that probing the
i2c bus is disabled by default as intended.
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.
Also strengthen chip detection for other TMP4xx chips,
and update driver support status for TMP431 and TMP432.
Write new function for various TMP4xx chips and separate
from lm90 detection.
Show that nct6775 driver supports NCT6792D.
Show that NCT6102D/6104D/6106D are supported by nct6775 driver.
NCT5573D is compatible to NCT6776F and has the same chip ID.
The bug was introduced when I added support for multiple fans
controlled by the same PWM output, in r6000. lm-sensors versions
affected: 3.3.2 to 3.3.5.
This fixes SUSE bug #903520:
https://bugzilla.suse.com/show_bug.cgi?id=903520
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.
Several kernel drivers have already moved their attributes from the
hardware device to the hwmon class device, and others will follow.
Teach fancontrol about this possibility and let it adjust the attribute
paths transparently.
With recent (>202) systemd release, syslog.target is no longer provided:
services are ensured they are started after logging socket is setup, so
journal will capture all syslog messages and will store them and forward
them to syslog implementation (if running).
Patch from Ville Skyttä.
Jean Delvare