summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2026-03-19hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs readSanman Pradhan1-9/+10
commit 25dd70a03b1f5f3aa71e1a5091ecd9cd2a13ee43 upstream. The q54sj108a2_debugfs_read function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'data_char' as the source. Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2C_SMBUS_BLOCK_MAX + 2), this writes 30 bytes past the end of the buffer onto the stack. Additionally, the arguments were swapped: it was reading from the zero-initialized 'data_char' and writing to 'data', resulting in all-zero output regardless of the actual I2C read. Fix this by: 1. Expanding 'data_char' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simple_read_from_buffer call. Fixes: d014538aa385 ("hwmon: (pmbus) Driver for Delta power supplies Q54SJ108A2") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260304235116.1045-1-sanman.p211993@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-12hwmon: (max6639) fix inverted polarityOlivier Sobrie1-1/+1
[ Upstream commit 170a4b21f49b3dcff3115b4c90758f0a0d77375a ] According to MAX6639 documentation: D1: PWM Output Polarity. PWM output is low at 100% duty cycle when this bit is set to zero. PWM output is high at 100% duty cycle when this bit is set to 1. Up to commit 0f33272b60ed ("hwmon: (max6639) : Update hwmon init using info structure"), the polarity was set to high (0x2) when no platform data was set. After the patch, the polarity register wasn't set anymore if no platform data was specified. Nowadays, since commit 7506ebcd662b ("hwmon: (max6639) : Configure based on DT property"), it is always set to low which doesn't match with the comment above and change the behavior compared to versions prior 0f33272b60ed. Fixes: 0f33272b60ed ("hwmon: (max6639) : Update hwmon init using info structure") Signed-off-by: Olivier Sobrie <olivier@sobrie.be> Link: https://lore.kernel.org/r/20260304212039.570274-1-olivier@sobrie.be Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-12hwmon: (it87) Check the it87_lock() return valueBart Van Assche1-1/+4
[ Upstream commit 07ed4f05bbfd2bc014974dcc4297fd3aa1cb88c0 ] Return early in it87_resume() if it87_lock() fails instead of ignoring the return value of that function. This patch suppresses a Clang thread-safety warning. Cc: Frank Crawford <frank@crawford.emu.id.au> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Jean Delvare <jdelvare@suse.com> Cc: linux-hwmon@vger.kernel.org Fixes: 376e1a937b30 ("hwmon: (it87) Add calls to smbus_enable/smbus_disable as required") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20260223220102.2158611-15-bart.vanassche@linux.dev [groeck: Declare 'ret' at the beginning of it87_resume()] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-12hwmon: (aht10) Fix initialization commands for AHT20Hao Yu1-2/+4
[ Upstream commit b7497b5a99f54ab8dcda5b14a308385b2fb03d8d ] According to the AHT20 datasheet (updated to V1.0 after the 2023.09 version), the initialization command for AHT20 is 0b10111110 (0xBE). The previous sequence (0xE1) used in earlier versions is no longer compatible with newer AHT20 sensors. Update the initialization command to ensure the sensor is properly initialized. While at it, use binary notation for DHT20_CMD_INIT to match the notation used in the datasheet. Fixes: d2abcb5cc885 ("hwmon: (aht10) Add support for compatible aht20") Signed-off-by: Hao Yu <haoyufine@gmail.com> Link: https://lore.kernel.org/r/20260222170332.1616-3-haoyufine@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-12hwmon: (aht10) Add support for dht20Akhilesh Patil2-6/+19
[ Upstream commit 3eaf1b631506e8de2cb37c278d5bc042521e82c1 ] Add support for dht20 temperature and humidity sensor from Aosong. Modify aht10 driver to handle different init command for dht20 sensor by adding init_cmd entry in the driver data. dht20 sensor is compatible with aht10 hwmon driver with this change. Tested on TI am62x SK board with dht20 sensor connected at i2c-2 port. Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in> Link: https://lore.kernel.org/r/2025112-94320-906858@bhairav-test.ee.iitb.ac.in Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: b7497b5a99f5 ("hwmon: (aht10) Fix initialization commands for AHT20") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-12hwmon: (max16065) Use READ/WRITE_ONCE to avoid compiler optimization induced ↵Gui-Dong Han1-13/+13
race [ Upstream commit 007be4327e443d79c9dd9e56dc16c36f6395d208 ] Simply copying shared data to a local variable cannot prevent data races. The compiler is allowed to optimize away the local copy and re-read the shared memory, causing a Time-of-Check Time-of-Use (TOCTOU) issue if the data changes between the check and the usage. To enforce the use of the local variable, use READ_ONCE() when reading the shared data and WRITE_ONCE() when updating it. Apply these macros to the three identified locations (curr_sense, adc, and fault) where local variables are used for error validation, ensuring the value remains consistent. Reported-by: Ben Hutchings <ben@decadent.org.uk> Closes: https://lore.kernel.org/all/6fe17868327207e8b850cf9f88b7dc58b2021f73.camel@decadent.org.uk/ Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") Fixes: b8d5acdcf525 ("hwmon: (max16065) Use local variable to avoid TOCTOU") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20260203121443.5482-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_faninFelix Gu1-0/+1
[ Upstream commit 4923bbff0bcffe488b3aa76829c829bd15b02585 ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In nct7363_present_pwm_fanin, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu <gu_0233@qq.com> Link: https://lore.kernel.org/r/tencent_9717645269E4C07D3D131F52201E12E5E10A@qq.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: (f71882fg) Add F81968 supportJi-Ze Hong (Peter Hong)1-2/+4
[ Upstream commit e4a3d6f79c9933fece64368168c46d6cf5fc2e52 ] Add hardware monitoring support for the Fintek F81968 Super I/O chip. It is fully compatible with F81866. Several products share compatibility with the F81866. To better distinguish between them, ensure that the Product ID is displayed when the device is probed. Signed-off-by: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Link: https://lore.kernel.org/r/20251223051040.10227-1-peter_hong@fintek.com.tw Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: (emc2305) Fix a resource leak in emc2305_of_parse_pwm_childFelix Gu1-0/+1
[ Upstream commit 2954ce672b7623478c1cfeb69e6a6e4042a3656e ] When calling of_parse_phandle_with_args(), the caller is responsible to call of_node_put() to release the reference of device node. In emc2305_of_parse_pwm_child, it does not release the reference, causing a resource leak. Signed-off-by: Felix Gu <gu_0233@qq.com> Link: https://lore.kernel.org/r/tencent_738BA80BBF28F3440301EEE6F9E470165105@qq.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: (nct6683) Add customer ID for ASRock Z590 TaichiAnj Duvnjak1-0/+3
[ Upstream commit c0fa7879c9850bd4597740a79d4fac5ebfcf69cc ] Add support for customer ID 0x1621 found on ASRock Z590 Taichi boards using the Nuvoton NCT6686D embedded controller. This allows the driver to instantiate without requiring the force=1 module parameter. Tested on two separate ASRock Z590 Taichi boards, both with EC firmware version 1.0 build 01/25/21. Signed-off-by: Anj Duvnjak <avian@extremenerds.net> Link: https://lore.kernel.org/r/20251222220942.10762-1-avian@extremenerds.net Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: (nct6775) Add ASUS Pro WS WRX90E-SAGE SEDenis Pauk1-0/+1
[ Upstream commit 246167b17c14e8a5142368ac6457e81622055e0a ] Boards Pro WS WRX90E-SAGE SE has got a nct6775 chip, but by default there's no use of it because of resource conflict with WMI method. Add the board to the WMI monitoring list. Link: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk <pauk.denis@gmail.com> Tested-by: Marcus <shoes2ga@gmail.com> Link: https://lore.kernel.org/r/20251231155316.2048-1-pauk.denis@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: (dell-smm) Add support for Dell OptiPlex 7080Armin Wolf1-0/+7
[ Upstream commit 46c3e87a79179454f741f797c274dd25f5c6125e ] The Dell OptiPlex 7080 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/16 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20260104000654.6406-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identificationCarl Lee1-0/+28
[ Upstream commit 9e33c1dba22431bea9b2bf48adf56859e52fc7ec ] When MPQ8785 reports VOUT_MODE as VID mode, mpq8785_identify() configures the driver for direct mode. The subsequent pmbus_identify_common() check then fails due to a mismatch between the reported mode and the configured mode, causing device initialization to fail. Override the reported VOUT_MODE to direct mode to keep the driver configuration consistent with the reported mode and allow successful device initialization. This does not change how voltages are interpreted, but avoids a false identification failure caused by mismatched mode handling. Fixes: f20b4a931130c ("hwmon: Add driver for MPS MPQ8785 Synchronous Step-Down Converter") Signed-off-by: Carl Lee <carl.lee@amd.com> Link: https://lore.kernel.org/r/20260210-dt-bindings-hwmon-pmbus-mpq8785-add-mpq8786-support-v3-1-84636ccfe76f@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27Revert "hwmon: (ibmpex) fix use-after-free in high/low store"Guenter Roeck1-7/+2
[ Upstream commit 8bde3e395a85017f12af2b0ba5c3684f5af9c006 ] This reverts commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d. Jean Delvare points out that the patch does not completely fix the reported problem, that it in fact introduces a (new) race condition, and that it may actually not be needed in the first place. Various AI reviews agree. Specific and relevant AI feedback: " This reordering sets the driver data to NULL before removing the sensor attributes in the loop below. ibmpex_show_sensor() retrieves this driver data via dev_get_drvdata() but does not check if it is NULL before dereferencing it to access data->sensors[]. If a userspace process reads a sensor file (like temp1_input) while this delete function is running, could it race with the dev_set_drvdata(..., NULL) call here and crash in ibmpex_show_sensor()? Would it be safer to keep the original order where device_remove_file() is called before clearing the driver data? device_remove_file() should wait for any active sysfs callbacks to complete, which might already prevent the use-after-free this patch intends to fix. " Revert the offending patch. If it can be shown that the originally reported alleged race condition does indeed exist, it can always be re-introduced with a complete fix. Reported-by: Jean Delvare <jdelvare@suse.de> Closes: https://lore.kernel.org/linux-hwmon/20260121095342.73e723cb@endymion/ Cc: Jean Delvare <jdelvare@suse.de> Cc: Junrui Luo <moonafterrain@outlook.com> Fixes: 6946c726c3f4 ("hwmon: (ibmpex) fix use-after-free in high/low store") Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-11hwmon: (occ) Mark occ_init_attribute() as __printfArnd Bergmann1-0/+1
[ Upstream commit 831a2b27914cc880130ffe8fb8d1e65a5324d07f ] This is a printf-style function, which gcc -Werror=suggest-attribute=format correctly points out: drivers/hwmon/occ/common.c: In function 'occ_init_attribute': drivers/hwmon/occ/common.c:761:9: error: function 'occ_init_attribute' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format] Add the attribute to avoid this warning and ensure any incorrect format strings are detected here. Fixes: 744c2fe950e9 ("hwmon: (occ) Rework attribute registration for stack usage") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20260203163440.2674340-1-arnd@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-11hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()Rafael J. Wysocki1-3/+14
[ Upstream commit 615901b57b7ef8eb655f71358f7e956e42bcd16b ] The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal. Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective. The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them. In addition, notice that hwmon_device_register_with_info() may fail in which case resource->hwmon_dev will become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case to acpi_power_meter_notify() and acpi_power_meter_remove(). Fixes: 16746ce8adfe ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register") Closes: https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ Reported-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-11hwmon: (dell-smm) Add Dell G15 5510 to fan control whitelistleobannocloutier@gmail.com1-0/+8
[ Upstream commit 830e0bef79aaaea8b1ef426b8032e70c63a58653 ] On the Dell G15 5510, fans spin at maximum speed when AC power is connected. This behavior has been observed as a regression in recent kernels (v6.18+). Add the Dell G15 5510 to the fan control whitelist to enable manual fan control and resolve the issue. This model requires the same fan control configuration as the Dell G15 5511. Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode") Signed-off-by: Leo Banno-Cloutier <leobannocloutier@gmail.com> Link: https://lore.kernel.org/r/20260117015315.214569-2-leobannocloutier@gmail.com [groeck: Updated patch description to follow guidance] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-11hwmon: (gpio-fan) Allow to stop FANs when CONFIG_PM is disabledGabor Juhos1-1/+1
commit 52fb36a5f9c15285b7d67c0ff87dc17b3206b5df upstream. When CONFIG_PM is disabled, the GPIO controlled FANs can't be stopped by using the sysfs attributes since commit 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support"). Using either the 'pwm1' or the 'fan1_target' attribute fails the same way: $ echo 0 > /sys/class/hwmon/hwmon1/pwm1 ash: write error: Function not implemented $ echo 0 > /sys/class/hwmon/hwmon1/fan1_target ash: write error: Function not implemented Both commands were working flawlessly before the mentioned commit. The issue happens because pm_runtime_put_sync() returns with -ENOSYS when CONFIG_PM is disabled, and the set_fan_speed() function handles this as an error. In order to restore the previous behaviour, change the error check in the set_fan_speed() function to ignore the -ENOSYS error code. Cc: stable@vger.kernel.org Fixes: 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://lore.kernel.org/r/20260202-gpio-fan-stop-fix-v1-1-c7853183d93d@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-11hwmon: (gpio-fan) Fix set_rpm() return valueGabor Juhos1-2/+2
commit f5c092787c48296633c2dd7240752f88fa9710fc upstream. The set_rpm function is used as a 'store' callback of a device attribute, and as such it should return with the number of bytes consumed. However since commit 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support"), the function returns with zero on success. Due to this, the function gets called again and again whenever the user tries to change the FAN speed by writing the desired RPM value into the 'fan1_target' sysfs attribute. The broken behaviour can be reproduced easily. For example, the following command never returns unless it gets terminated: $ echo 500 > /sys/class/hwmon/hwmon1/fan1_target ^C $ Change the code to return with the same value as the 'count' parameter on success to indicate that all bytes from the input buffer are consumed. The function behaved the same way prior to the offending change. Cc: stable@vger.kernel.org Fixes: 0d01110e6356 ("hwmon: (gpio-fan) Add regulator support") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://lore.kernel.org/r/20260201-gpio-fan-set_rpm-retval-fix-v1-1-dc39bc7693ca@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-08hwmon: (dell-smm) Fix off-by-one error in dell_smm_is_visible()Armin Wolf1-2/+2
commit fae00a7186cecf90a57757a63b97a0cbcf384fe9 upstream. The documentation states that on machines supporting only global fan mode control, the pwmX_enable attributes should only be created for the first fan channel (pwm1_enable, aka channel 0). Fix the off-by-one error caused by the fact that fan channels have a zero-based index. Cc: stable@vger.kernel.org Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20251203202109.331528-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-02hwmon: (w83l786ng) Convert macros to functions to avoid TOCTOUGui-Dong Han1-8/+18
commit 07272e883fc61574b8367d44de48917f622cdd83 upstream. The macros FAN_FROM_REG and TEMP_FROM_REG evaluate their arguments multiple times. When used in lockless contexts involving shared driver data, this causes Time-of-Check to Time-of-Use (TOCTOU) race conditions. Convert the macros to static functions. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions. Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/ Fixes: 85f03bccd6e0 ("hwmon: Add support for Winbond W83L786NG/NR") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20251128123816.3670-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-02hwmon: (w83791d) Convert macros to functions to avoid TOCTOUGui-Dong Han1-6/+11
commit 670d7ef945d3a84683594429aea6ab2cdfa5ceb4 upstream. The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors. Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions. Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data. Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/ Fixes: 9873964d6eb2 ("[PATCH] HWMON: w83791d: New hardware monitoring driver for the Winbond W83791D") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20251202180105.12842-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-02hwmon: (max6697) fix regmap leak on probe failureJohan Hovold1-1/+1
commit 02f0ad8e8de8cf5344f8f0fa26d9529b8339da47 upstream. The i2c regmap allocated during probe is never freed. Switch to using the device managed allocator so that the regmap is released on probe failures (e.g. probe deferral) and on driver unbind. Fixes: 3a2a8cc3fe24 ("hwmon: (max6697) Convert to use regmap") Cc: stable@vger.kernel.org # 6.12 Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20251127134351.1585-1-johan@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-02hwmon: (max16065) Use local variable to avoid TOCTOUGui-Dong Han1-3/+4
commit b8d5acdcf525f44e521ca4ef51dce4dac403dab4 upstream. In max16065_current_show, data->curr_sense is read twice: once for the error check and again for the calculation. Since i2c_smbus_read_byte_data returns negative error codes on failure, if the data changes to an error code between the check and the use, ADC_TO_CURR results in an incorrect calculation. Read data->curr_sense into a local variable to ensure consistency. Note that data->curr_gain is constant and safe to access directly. This aligns max16065_current_show with max16065_input_show, which already uses a local variable for the same reason. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z8B-g@mail.gmail.com/ Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20251128124709.3876-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-02hwmon: (emc2305) fix double put in emc2305_probe_childs_from_dtPei Xiao1-3/+1
[ Upstream commit 541dfb49dcb80c2509e030842de77adfb77820f5 ] ./drivers/hwmon/emc2305.c:597:4-15: ERROR: probable double put Device node iterators put the previous value of the index variable, so an explicit put causes a double put. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/tencent_CD373F952BE48697C949E39CB5EB77841D06@qq.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-02hwmon: (emc2305) fix device node refcount leak in error pathPei Xiao1-1/+3
[ Upstream commit 4910da6b36b122db50a27fabf6ab7f8611b60bf8 ] The for_each_child_of_node() macro automatically manages device node reference counts during normal iteration. However, when breaking out of the loop early with return, the current iteration's node is not automatically released, leading to a reference count leak. Fix this by adding of_node_put(child) before returning from the loop when emc2305_set_single_tz() fails. This issue could lead to memory leaks over multiple probe cycles. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/tencent_5CDC08544C901D5ECA270573D5AEE3117108@qq.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-02hwmon: (ltc4282): Fix reset_history file permissionsNuno Sá1-3/+6
[ Upstream commit b3db91c3bfea69a6c6258fea508f25a59c0feb1a ] The reset_history attributes are write only. Hence don't report them as readable just to return -EOPNOTSUPP later on. Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20251219-ltc4282-fix-reset-history-v1-1-8eab974c124b@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-02hwmon: (tmp401) fix overflow caused by default conversion rate valueAlexey Simakov1-1/+1
[ Upstream commit 82f2aab35a1ab2e1460de06ef04c726460aed51c ] The driver computes conversion intervals using the formula: interval = (1 << (7 - rate)) * 125ms where 'rate' is the sensor's conversion rate register value. According to the datasheet, the power-on reset value of this register is 0x8, which could be assigned to the register, after handling i2c general call. Using this default value causes a result greater than the bit width of left operand and an undefined behaviour in the calculation above, since shifting by values larger than the bit width is undefined behaviour as per C language standard. Limit the maximum usable 'rate' value to 7 to prevent undefined behaviour in calculations. Found by Linux Verification Center (linuxtesting.org) with Svace. Note (groeck): This does not matter in practice unless someone overwrites the chip configuration from outside the driver while the driver is loaded. The conversion time register is initialized with a value of 5 (500ms) when the driver is loaded, and the driver never writes a bad value. Fixes: ca53e7640de7 ("hwmon: (tmp401) Convert to _info API") Signed-off-by: Alexey Simakov <bigalex934@gmail.com> Link: https://lore.kernel.org/r/20251211164342.6291-1-bigalex934@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-02hwmon: (ibmpex) fix use-after-free in high/low storeJunrui Luo1-2/+7
[ Upstream commit 6946c726c3f4c36f0f049e6f97e88c510b15f65d ] The ibmpex_high_low_store() function retrieves driver data using dev_get_drvdata() and uses it without validation. This creates a race condition where the sysfs callback can be invoked after the data structure is freed, leading to use-after-free. Fix by adding a NULL check after dev_get_drvdata(), and reordering operations in the deletion path to prevent TOCTOU. Reported-by: Yuhao Jiang <danisjiang@gmail.com> Reported-by: Junrui Luo <moonafterrain@outlook.com> Fixes: 57c7c3a0fdea ("hwmon: IBM power meter driver") Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Link: https://lore.kernel.org/r/MEYPR01MB7886BE2F51BFE41875B74B60AFA0A@MEYPR01MB7886.ausprd01.prod.outlook.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-02hwmon: (dell-smm) Limit fan multiplier to avoid overflowDenis Sergeev1-0/+9
[ Upstream commit 46c28bbbb150b80827e4bcbea231560af9d16854 ] The fan nominal speed returned by SMM is limited to 16 bits, but the driver allows the fan multiplier to be set via a module parameter. Clamp the computed fan multiplier so that fan_nominal_speed * i8k_fan_mult always fits into a signed 32-bit integer and refuse to initialize the driver if the value is too large. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 20bdeebc88269 ("hwmon: (dell-smm) Introduce helper function for data init") Signed-off-by: Denis Sergeev <denserg.edu@gmail.com> Link: https://lore.kernel.org/r/20251209063706.49008-1-denserg.edu@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-18hwmon: sy7636a: Fix regulator_enable resource leak on error pathHaotian Zhang1-6/+1
[ Upstream commit 2f88425ef590b7fcc2324334b342e048edc144a9 ] In sy7636a_sensor_probe(), regulator_enable() is called but if devm_hwmon_device_register_with_info() fails, the function returns without calling regulator_disable(), leaving the regulator enabled and leaking the reference count. Switch to devm_regulator_get_enable() to automatically manage the regulator resource. Fixes: de34a4053250 ("hwmon: sy7636a: Add temperature driver for sy7636a") Suggested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Link: https://lore.kernel.org/r/20251126162602.2086-1-vulab@iscas.ac.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-12hwmon: (gpd-fan) initialize EC on driver load for Win 4Cryolitia PukNgae1-27/+25
The original implement will re-init the EC when it reports a zero value, and it's a workaround for the black box buggy firmware. Now a contributer test and report that, the bug is that, the firmware won't initialize the EC on boot, so the EC ramains in unusable status. And it won't need to re-init it during runtime. The original implement is not perfect, any write command will be ignored until we first read it. Just re-init it unconditionally when the driver load could work. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Co-developed-by: kylon <3252255+kylon@users.noreply.github.com> Signed-off-by: kylon <3252255+kylon@users.noreply.github.com> Link: https://github.com/Cryolitia/gpd-fan-driver/pull/20 Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com> Link: https://lore.kernel.org/r/20251030-win4-v1-1-c374dcb86985@uniontech.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-11-12hwmon: (gpd-fan) Fix compilation error in non-ACPI buildsGopi Krishna Menon1-1/+1
Building gpd-fan driver without CONFIG_ACPI results in the following build errors: drivers/hwmon/gpd-fan.c: In function ‘gpd_ecram_read’: drivers/hwmon/gpd-fan.c:228:9: error: implicit declaration of function ‘outb’ [-Werror=implicit-function-declaration] 228 | outb(0x2E, addr_port); | ^~~~ drivers/hwmon/gpd-fan.c:241:16: error: implicit declaration of function ‘inb’ [-Werror=implicit-function-declaration] 241 | *val = inb(data_port); The definitions for inb() and outb() come from <linux/io.h> (specifically through <asm/io.h>), which is implicitly included via <acpi_io.h>. When CONFIG_ACPI is not set, <acpi_io.h> is not included resulting in <linux/io.h> to be omitted as well. Since the driver does not depend on ACPI, remove <linux/acpi.h> and add <linux/io.h> directly to fix the compilation errors. Signed-off-by: Gopi Krishna Menon <krishnagopi487@gmail.com> Link: https://lore.kernel.org/r/20251024202042.752160-1-krishnagopi487@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-20hwmon: (sht3x) Fix error handlingGuenter Roeck1-10/+17
Handling of errors when reading status, temperature, and humidity returns the error number as negative attribute value. Fix it up by returning the error as return value. Fixes: a0ac418c6007c ("hwmon: (sht3x) convert some of sysfs interface to hwmon") Cc: JuenKit Yip <JuenKit_Yip@hotmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-20hwmon: (cgbc-hwmon) Add missing NULL check after devm_kzalloc()Li Qiang1-0/+3
The driver allocates memory for sensor data using devm_kzalloc(), but did not check if the allocation succeeded. In case of memory allocation failure, dereferencing the NULL pointer would lead to a kernel crash. Add a NULL pointer check and return -ENOMEM to handle allocation failure properly. Signed-off-by: Li Qiang <liqiang01@kylinos.cn> Fixes: 08ebc9def79fc ("hwmon: Add Congatec Board Controller monitoring driver") Reviewed-by: Thomas Richard <thomas.richard@bootlin.com> Link: https://lore.kernel.org/r/20251017063414.1557447-1-liqiang01@kylinos.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-20hwmon: (pmbus/isl68137) Fix child node reference leak on early returnErick Karanja1-2/+1
In the case of an early return, the reference to the child node needs to be released. Use for_each_child_of_node_scoped to fix the issue. Fixes: 3996187f80a0e ("hwmon: (pmbus/isl68137) add support for voltage divider on Vout") Signed-off-by: Erick Karanja <karanja99erick@gmail.com> Link: https://lore.kernel.org/r/20251012181249.359401-1-karanja99erick@gmail.com [groeck: Updated subject/description] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-20hwmon: (gpd-fan) Fix error handling in gpd_fan_probe()Harshit Mogalapalli1-3/+3
devm_request_region() returns a NULL pointer on error, not an ERR_PTR(). Handle it accordingly. Also fix error return from the call to devm_hwmon_device_register_with_info(). Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Cryolitia PukNgae <cryolitia@uniontech.com> Link: https://lore.kernel.org/r/20251010204447.94343-1-harshit.m.mogalapalli@oracle.com [groeck: Updated subject to improve readability] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-20hwmon: (gpd-fan) Fix return value when platform_get_resource() failsHarshit Mogalapalli1-2/+2
When platform_get_resource() fails it returns NULL and not an error pointer, accordingly change the error handling. Fixes: 0ab88e239439 ("hwmon: add GPD devices sensor driver") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20251010204359.94300-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-20hwmon: (pmbus/max34440) Update adpm12160 coeff due to latest FWAlexis Czezar Torreno1-6/+6
adpm12160 is a dc-dc power module. The firmware was updated and the coeeficients in the pmbus_driver_info needs to be updated. Since the part has not yet released with older FW, this permanent change to reflect the latest should be ok. Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com> Link: https://lore.kernel.org/r/20251001-hwmon-next-v1-1-f8ca6a648203@analog.com Fixes: 629cf8f6c23a ("hwmon: (pmbus/max34440) Add support for ADPM12160") Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-10-01Merge tag 'gpio-updates-for-v6.18-rc1' of ↵Linus Torvalds3-0/+960
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "There are two new drivers and support for more models in existing ones. The generic GPIO API has been reworked and all users converted which allowed us to move the fields specific to the generic GPIO implementation out of the high-level struct gpio_chip into its own structure that wraps the gpio_chip. Other than that, there's nothing too exciting. Mostly minor tweaks and fixes all over the place, some refactoring and some small new features in helper modules. GPIO core: - add support for sparse pin ranges to the glue between GPIO and pinctrl - use a common prefix across all GPIO descriptor flags for improved namespacing New drivers: - add new GPIO driver for the Nuvoton NCT6694 - add new GPIO driver for MAX7360 Driver improvements: - add support for Tegra 256 to the gpio-tegra186 driver - add support for Loongson-2K0300 to the gpio-loongson-64bit driver - refactor the gpio-aggregator module to expose its GPIO forwarder API to other in-kernel users (to enable merging of a new pinctrl driver that uses it) - convert all remaining drivers to using the modernized generic GPIO chip API and remove the old interface - stop displaying global GPIO numbers in debugfs output of controller drivers - extend the gpio-regmap helper with a new config option and improve its support for GPIO interrupts - remove redundant fast_io parameter from regmap configs in GPIO drivers that already use MMIO regmaps which imply it - add support for a new model in gpio-mmio: ixp4xx expansion bus - order includes alphabetically in a few drivers for better readability - use generic device properties where applicable - use devm_mutex_init() where applicable - extend build coverage of drivers by enabling more to be compiled with COMPILE_TEST enabled - allow building gpio-stmpe as a module - use dev_err_probe() where it makes sense in drivers Late driver fixes: - fix setting GPIO direction to output in gpio-mpfs Documentation: - document the usage of software nodes with GPIO chips Device-tree bindings: - Add DT bindings documents for new hardware: Tegra256, MAX7360 - Document a new model in Loongson bindings: LS2K0300 - Document a new model using the generic GPIO binding: IXP4xx - Convert the DT binding for fsl,mxs-pinctrl to YAML - fix the schema ID in the "trivial" GPIO schema - describe GPIO hogs in the generic GPIO binding" * tag 'gpio-updates-for-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (122 commits) gpio: mpfs: fix setting gpio direction to output gpio: generic: move GPIO_GENERIC_ flags to the correct header gpio: generic: rename BGPIOF_ flags to GPIO_GENERIC_ gpio: nomadik: fix the debugfs helper stub MAINTAINERS: Add entry on MAX7360 driver input: misc: Add support for MAX7360 rotary input: keyboard: Add support for MAX7360 keypad gpio: max7360: Add MAX7360 gpio support gpio: regmap: Allow to provide init_valid_mask callback gpio: regmap: Allow to allocate regmap-irq device pwm: max7360: Add MAX7360 PWM support pinctrl: Add MAX7360 pinctrl driver mfd: Add max7360 support dt-bindings: mfd: gpio: Add MAX7360 rtc: Add Nuvoton NCT6694 RTC support hwmon: Add Nuvoton NCT6694 HWMON support watchdog: Add Nuvoton NCT6694 WDT support can: Add Nuvoton NCT6694 CANFD support i2c: Add Nuvoton NCT6694 I2C support gpio: Add Nuvoton NCT6694 GPIO support ...
2025-09-25hwmon: (mlxreg-fan) Add support for new flavour of capability registerVadim Pasternak1-3/+15
FAN platform data is common across the various systems, while fan driver should be able to apply only the fan instances relevant to specific system. For example, platform data might contain descriptions for fan1, fan2, ..., fan{n}, while some systems equipped with all 'n' fans, others with less. Also, on some systems fan drawer can be equipped with several tachometers and on others only with one. For detection of the real number of equipped drawers and tachometers special capability registers are used. These registers used to indicate presence of drawers and tachometers through the bitmap. For some new big modular systems this register will provide presence data by counter. Use slot parameter to distinct whether capability register contains bitmask or counter. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20250113084859.27064-3-vadimp@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25hwmon: (mlxreg-fan) Separate methods of fan setting coming from different ↵Vadim Pasternak1-8/+16
subsystems Distinct between fan speed setting request coming for hwmon and thermal subsystems. There are fields 'last_hwmon_state' and 'last_thermal_state' in the structure 'mlxreg_fan_pwm', which respectively store the cooling state set by the 'hwmon' and 'thermal' subsystem. The purpose is to make arbitration of fan speed setting. For example, if fan speed required to be not lower than some limit, such setting is to be performed through 'hwmon' subsystem, thus 'thermal' subsystem will not set fan below this limit. Currently, the 'last_thermal_state' is also be updated by 'hwmon' causing cooling state to never be set to a lower value. Eliminate update of 'last_thermal_state', when request is coming from 'hwmon' subsystem. Fixes: da74944d3a46 ("hwmon: (mlxreg-fan) Use pwm attribute for setting fan speed low limit") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20250113084859.27064-2-vadimp@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25hwmon: (cros_ec) register fans into thermal framework cooling devicesSung-Chi Li1-0/+83
Register fans connected under EC as thermal cooling devices as well, so these fans can then work with the thermal framework. During the driver probing phase, we will also try to register each fan as a thermal cooling device based on previous probe result (whether the there are fans connected on that channel, and whether EC supports fan control). The basic get max state, get current state, and set current state methods are then implemented as well. Signed-off-by: Sung-Chi Li <lschyi@chromium.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20250911-cros_ec_fan-v6-3-a1446cc098af@google.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25hwmon: (cros_ec) add PWM control over fansSung-Chi Li1-0/+230
Newer EC firmware supports controlling fans through host commands, so adding corresponding implementations for controlling these fans in the driver for other kernel services and userspace to control them. The driver will first probe the supported host command versions (get and set of fan PWM values, get and set of fan control mode) to see if the connected EC fulfills the requirements of controlling the fan, then exposes corresponding sysfs nodes for userspace to control the fan with corresponding read and write implementations. As EC will automatically change the fan mode to auto when the device is suspended, the power management hooks are added as well to keep the fan control mode and fan PWM value consistent during suspend and resume. As we need to access the hwmon device in the power management hook, update the driver by storing the hwmon device in the driver data as well. Signed-off-by: Sung-Chi Li <lschyi@chromium.org> Acked-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20250911-cros_ec_fan-v6-2-a1446cc098af@google.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25hwmon: add SMARC-sAM67 supportMichael Walle3-0/+172
Add a new driver for the Kontron SMARC-sAM67 board management controller. It has two voltage sensors and one temperature sensor. Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://lore.kernel.org/r/20250912120745.2295115-7-mwalle@kernel.org [groeck: Added sa67 to index.rst] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-25hwmon: (asus-ec-sensors) add TUF GAMING X670E PLUS WIFIMohamad Kamal1-0/+2
Add support for TUF GAMING X670E PLUS WIFI Signed-off-by: Mohamad Kamal <mohamad.kamal.85@gmail.com> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20250914084019.1108941-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-24hwmon: (dell-smm) Add support for Dell OptiPlex 7040Armin Wolf1-0/+7
The Dell OptiPlex 7040 supports the legacy SMM interface for reading sensors and performing fan control. Whitelist this machine so that this driver loads automatically. Closes: https://github.com/Wer-Wolf/i8kutils/issues/15 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250917181036.10972-5-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-24hwmon: (dell-smm) Add support for automatic fan modeArmin Wolf1-13/+61
Many machines treat fan state 3 as some sort of automatic mode, which is superior to the separate SMM calls for switching to automatic fan mode for two reasons: - the fan control mode can be controlled for each fan separately - the current fan control mode can be retrieved from the BIOS On some machines however, this special fan state does not exist. Fan state 3 acts like a regular fan state on such machines or does not exist at all. Such machines usually use separate SMM calls for enabling/disabling automatic fan control. Add support for it. If the machine supports separate SMM calls for changing the fan control mode, then the other interface is ignored. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250917181036.10972-4-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-24hwmon: (gpd-fan) complete Kconfig dependenciesCryolitia PukNgae1-1/+1
DMI and HAS_IOPORT is also needed Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202509200214.i2QX7iwD-lkp@intel.com/ Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com> Link: https://lore.kernel.org/r/20250924-hwmon2-v1-1-fc529865a325@uniontech.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-24hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutexBen Copeland1-1/+1
Some motherboards require more time to acquire the ACPI mutex, causing "Failed to acquire mutex" messages to appear in the kernel log. Increase the timeout from 500ms to 800ms to accommodate these cases. Signed-off-by: Ben Copeland <ben.copeland@linaro.org> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20250923192935.11339-3-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-30 04:57:50 +0300