This driver exposes hardware sensors of the Gigabyte AORUS Waterforce
all-in-one CPU liquid coolers, which communicate through a proprietary
USB HID protocol. Report offsets were initially discovered in [1] and
confirmed by me on a Waterforce X240 by observing the sent reports from
the official software.
Available sensors are pump and fan speed in RPM, as well as coolant
temperature. Also available through debugfs is the firmware version.
Attaching a fan is optional and allows it to be controlled from the
device. If it's not connected, the fan-related sensors will report
zeroes.
The addressable RGB LEDs and LCD screen are not supported in this
driver and should be controlled through userspace tools.
[1]: https://github.com/liquidctl/liquidctl/issues/167
Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com>
Link: https://lore.kernel.org/r/20231207122402.107032-1-savicaleksa83@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/a732270539ef63094a32d0ff582f78e640caf3e4.1701957841.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Added custom channel-specific (temp1) attribute for resolution. The wait
time for a conversion in one-shot mode (enable = 0) depends on the
resolution.
When resolution is 12-bit, the conversion time is 140ms, but the minimum
update_interval is 125ms. Handled this problem by waiting an additional
15ms (125ms + 15ms = 140ms).
Added 'mask' parameter to the shutdown_write() function. Now it can
either write or update bits, depending on the value of mask. This is
needed, because for alarms a write is necessary, but for resolution only
the resolution bits should be updated.
Signed-off-by: Daniel Matyas <daniel.matyas@analog.com>
Link: https://lore.kernel.org/r/20231031182158.124608-5-daniel.matyas@analog.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Currently, i8k_dmi_table contains both entries used for DMI
matching and entries used to override config options. This
does not allow for differentiating between "its safe to issue
raw SMM calls on this machine" and "its not safe to issue raw
SMM calls on this machine, but here are some config values".
Since future SMM backends will need to differentiate between
those two cases, move those config entries into a separate
table. i8k_dmi_table now serves as a general "its safe to issue
raw SMM calls" table.
Tested-by: <serverror@serverror.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://lore.kernel.org/r/20231123004820.50635-6-W_Armin@gmx.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The EliteDesk 800 G6 stores a raw WMI string within the ACPI object in its
BIOS corresponding to one instance of HPBIOS_PlatformEvents.Name. This is
evidently a valid way of representing a WMI data item as far as the
Microsoft ACPI-WMI mapper is concerned, but is preventing the driver from
loading.
This seems quite rare, but add support for such strings. Treating this as a
quirk pretty much means adding that support anyway.
Also clean up an oversight in update_numeric_sensor_from_wobj() in which
the result of hp_wmi_strdup() was being used without error checking.
Reported-by: Lukasz Stelmach <l.stelmach@samsung.com>
Closes: https://lore.kernel.org/linux-hwmon/7850a0bd-60e7-88f8-1d6c-0bb0e3234fdc@roeck-us.net/
Tested-by: Lukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: James Seo <james@equiv.tech>
Link: https://lore.kernel.org/r/20231123054918.157098-1-james@equiv.tech
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The PECI CPU sensors are available as soon as the CPU is powered,
however the PECI DIMM sensors are available after DRAM has been
trained and thresholds have been written by host firmware.
The default timeout of 30 seconds isn't enough for modern multisocket
platforms utilizing DDR5 memory to bring up the memory and enable PECI
sensor data.
Bump the default timeout to 10 minutes in case the system starts
without cached DDR5 training data.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20231130090422.2535542-1-patrick.rudolph@9elements.com
[groeck: List affected driver in patch subject]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Without visibility into the initializers for data->innr, GCC suspects
using it as an index could walk off the end of the various 14-element
arrays in data. Perform an explicit clamp to the array size. Silences
the following warning with GCC 12+:
../drivers/hwmon/pc87360.c: In function 'pc87360_update_device':
../drivers/hwmon/pc87360.c:341:49: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
341 | data->in_max[i] = pc87360_read_value(data,
| ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
342 | LD_IN, i,
| ~~~~~~~~~
343 | PC87365_REG_IN_MAX);
| ~~~~~~~~~~~~~~~~~~~
../drivers/hwmon/pc87360.c:209:12: note: at offset 255 into destination object 'in_max' of size 14
209 | u8 in_max[14]; /* Register value */
| ^~~~~~
Cc: Jim Cromie <jim.cromie@gmail.com>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20231130200207.work.679-kees@kernel.org
[groeck: Added comment into code clarifying context]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
This attribute is defined as read-only by all drivers that support it.
It seems that the access rights and description for this attribute were
copied from the intrusionY_alarm, which has indeed RW rights and must be
cleared by the user.
These are the modules that currently use this attribute:
- adt7x10
- i5500_temp
- jc42
- lm83
- lm90
- lm95245
- max31760
- max6621
- mc34vr500
- tmp401
- tmp464
- tmp513
Fix the attribute description and make it read-only.
Fixes: 365b5d63a5 ("ABI: sysfs-class-hwmon: add a description for tempY_crit_alarm")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231116-hwmon_abi-v1-3-8bfb7f51145a@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
All these attributes already exist and are used by the hwmon subsystem,
but they still must be documented.
The missing attributes are the following:
- humidityY_alarm
- humidityY_fault
- humidityY_label
- humidityY_max
- humidityY_max_hyst
- humidityY_min
- humidityY_min_hyst
Add the missing humidity attributes to the ABI documentation according
to their current usage and access rights in the hwmon subsystem.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231116-hwmon_abi-v1-2-8bfb7f51145a@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Preliminary step to add the missing humidity attributes in the ABI
documentation.
Adding new elements alphabetically is a common practice that has been
loosely followed in the sysfs-class-hwmon documentation. Since most of
the humidity attributes must be added to the file, a single attribute
needs to be rearranged to reinforce alphabetical order.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231116-hwmon_abi-v1-1-8bfb7f51145a@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use preferred i2c_get_match_data() instead of of_match_device() and
i2c_match_id() to get the driver match data. With this, adjust the
includes to explicitly include the correct headers.
Adjust the 'chips' enum to not use 0, so that no match data can be
distinguished from a valid enum value.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231115205703.3730448-3-robh@kernel.org
[groeck: Use double cast for enum chips assignment to make compiler happy]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Changing the "kinds" enum start value to be 1-indexed instead of
0-indexed caused look-ups in nct6775_device_names[] to be misaligned or
off the end.
Initialize the string list with explicit indexes.
Cc: Rob Herring <robh@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Fixes: 10a0575ea0 ("hwmon: nct6775-i2c: Use i2c_get_match_data()")
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Use preferred i2c_get_match_data() instead of of_match_device() and
i2c_match_id() to get the driver match data. With this, adjust the
includes to explicitly include the correct headers.
Adjust the 'kinds' enum to not use 0, so that no match data can be
distinguished from a valid enum value.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231115205703.3730448-2-robh@kernel.org
[groeck: Use double cast for i2c_get_match_data() to make clang happy]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Based on the documentation below, the maximum number of Fan tach
channels is 16:
Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt:45:
45 - aspeed,fan-tach-ch : should specify the Fan tach input channel.
46 integer value in the range 0 through 15, with 0 indicating
47 Fan tach channel 0 and 15 indicating Fan tach channel 15.
48 At least one Fan tach input channel is required.
However, the compiler doesn't know that, and legitimaly warns about a potential
overwrite in array `u8 fan_tach_ch_source[16]` in `struct aspeed_pwm_tacho_data`,
in case `index` takes a value outside the boundaries of the array:
drivers/hwmon/aspeed-pwm-tacho.c:
179 struct aspeed_pwm_tacho_data {
...
184 bool fan_tach_present[16];
...
193 u8 fan_tach_ch_source[16];
196 };
In function ‘aspeed_create_fan_tach_channel’,
inlined from ‘aspeed_create_fan’ at drivers/hwmon/aspeed-pwm-tacho.c:877:2,
inlined from ‘aspeed_pwm_tacho_probe’ at drivers/hwmon/aspeed-pwm-tacho.c:936:9:
drivers/hwmon/aspeed-pwm-tacho.c:751:49: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
751 | priv->fan_tach_ch_source[index] = pwm_source;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
drivers/hwmon/aspeed-pwm-tacho.c: In function ‘aspeed_pwm_tacho_probe’:
drivers/hwmon/aspeed-pwm-tacho.c:193:12: note: at offset [48, 255] into destination object ‘fan_tach_ch_source’ of size 16
193 | u8 fan_tach_ch_source[16];
| ^~~~~~~~~~~~~~~~~~
Fix this by sanity checking `index` before using it to index arrays of
size 16 elements in `struct aspeed_pwm_tacho_data`. Also, pass `dev` as
argument to function `aspeed_create_fan_tach_channel()`, and add an error
message in case `index` is out-of-bounds, in which case return `-EINVAL`.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/ZVPQJIP26dIzRAr6@work
[groeck: Fixed continuation line alignment]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Adding Pulse Width Modulation (PWM) and fan tacho NPCM8xx support to
NPCM PWM and fan tacho driver.
NPCM8xx uses a different number of PWM devices.
As part of adding NPCM8XX support:
- Add NPCM8xx specific compatible string.
- Add data to handle architecture-specific PWM parameters.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Link: https://lore.kernel.org/r/20231031075806.400872-2-tmaimon77@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
