Most mainboards need a config file which describe which input of a
monitoring chip is connected to which voltage rail, what are scaling
factors of voltages that can't be measured directly by the chip, which
part of the board has each temperature sensor, which fan is connected to
which tachometer input of the chip, etc.
All these data need to be determined either from a board schematic (if
available) or by a trial-and-error method.
This can be a time consuming and error-prone work, fortunately, it needs to
be done just once per mainboard.
Currently, however, there is no standard mechanism to share such
configurations so multiple users of the same board don't basically waste
their time reinventing the wheel (or recreating the same configuration
again and again).
Previously, a wiki on an old lm-sensors site had a 'Configurations' page
where contributors could submit their configurations.
Since this site is down for two years now and it does not look like it is
coming back we need to find an another solution.
Let's use a 'configs' directory in project repository for these files, so
we can benefit from SCM infrastructure for managing them.
Also, add a reminder in documentation asking people to contribute these
files for benefit of the whole community and configurations for 3
mainboards for a starter.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
DDR4 SPD is quite similar to DDR3 SPD. Key difference for detection is
the DDR type, which is 0x0c or 12 for DDR4.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Construct "wait $!" causes bash to remember the exit status of the
children. This consumes memory. We don't need the status code and we
are only waiting for a single child, so we can simply use "wait". This
will reduce the memory usage.
This partly fixes ticket #2391.
http://www.lm-sensors.org/ticket/2391
The actual leak is in bash 4.3 and should be fixed there.
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