summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
2026-03-25hwmon: (max6639) Fix pulses-per-revolution implementationGuenter Roeck1-5/+5
[ Upstream commit e7bae9a7a5e1251ab414291f4e9304d702bb9221 ] The valid range for the pulses-per-revolution devicetree property is 1..4. The current code checks for a range of 1..5. Fix it. Declare the variable used to retrieve pulses per revolution from devicetree as u32 (unsigned) to match the of_property_read_u32() API. The current code uses a postfix decrement when writing the pulses per resolution into the chip. This has no effect since the value is evaluated before it is decremented. Fix it by decrementing before evaluating the value. Fixes: 7506ebcd662b ("hwmon: (max6639) : Configure based on DT property") Cc: Naresh Solanki <naresh.solanki@9elements.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-25hwmon: (pmbus/isl68137) Fix unchecked return value and use sysfs_emit()Sanman Pradhan1-2/+5
commit 86259558e422b250aa6aa57163a6d759074573f5 upstream. isl68137_avs_enable_show_page() uses the return value of pmbus_read_byte_data() without checking for errors. If the I2C transaction fails, a negative error code is passed through bitwise operations, producing incorrect output. Add an error check to propagate the return value if it is negative. Additionally, modernize the callback by replacing sprintf() with sysfs_emit(). Fixes: 038a9c3d1e424 ("hwmon: (pmbus/isl68137) Add driver for Intersil ISL68137 PWM Controller") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260318193952.47908-2-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-25hwmon: (pmbus/mp2975) Add error check for pmbus_read_word_data() return valueSanman Pradhan1-0/+2
commit 19d4b9c8a136704d5f2544e7ac550f27918a5004 upstream. mp2973_read_word_data() XORs the return value of pmbus_read_word_data() with PB_STATUS_POWER_GOOD_N without first checking for errors. If the I2C transaction fails, a negative error code is XORed with the constant, producing a corrupted value that is returned as valid status data instead of propagating the error. Add the missing error check before modifying the return value. Fixes: acda945afb465 ("hwmon: (pmbus/mp2975) Fix PGOOD in READ_STATUS_WORD") Cc: stable@vger.kernel.org Signed-off-by: Sanman Pradhan <psanman@juniper.net> Link: https://lore.kernel.org/r/20260317173308.382545-3-sanman.pradhan@hpe.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-25hwmon: (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-13hwmon: (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-13hwmon: (max6639) : Configure based on DT propertyNaresh Solanki1-23/+60
[ Upstream commit 7506ebcd662b868780774d191a7c024c18c557a8 ] Remove platform data & initialize with defaults configuration & overwrite based on DT properties. Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> Message-ID: <20241007090426.811736-1-naresh.solanki@9elements.com> [groeck: Dropped some unnecessary empty lines] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 170a4b21f49b ("hwmon: (max6639) fix inverted polarity") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-13hwmon: (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-13hwmon: (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-13hwmon: (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-13hwmon: (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: (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: (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-03-04hwmon: (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-03-04hwmon: pmbus: mpq8785: Add support for MPM82504Pawel Dembicki1-1/+28
[ Upstream commit c27291468eb957b11dc81cd35fad36faf0861c07 ] Add support for the Monolithic Power Systems MPM82504 digital voltage regulator. MPM82504 uses PMBus direct format for voltage output. Tested with device tree based matching. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-5-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 9e33c1dba224 ("hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: pmbus: mpq8785: Implement VOUT feedback resistor divider ratio ↵Pawel Dembicki1-0/+18
configuration [ Upstream commit dc1a4bab48d513e426118e42b9c371d942ddb04b ] Implement support for setting the VOUT_SCALE_LOOP PMBus register based on an optional device tree property "mps,vout-fb-divider-ratio-permille". This allows the driver to provide the correct VOUT value depending on the feedback voltage divider configuration for chips where the bootloader does not configure the VOUT_SCALE_LOOP register. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-4-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 9e33c1dba224 ("hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04hwmon: pmbus: mpq8785: Prepare driver for multiple device supportPawel Dembicki1-8/+30
[ Upstream commit 1bc6020dc400ea8290a7b26aa4365d4568e23e27 ] Refactor the driver to support multiple Monolithic Power Systems devices. Introduce chip ID handling based on device tree matching. No functional changes intended. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-3-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 9e33c1dba224 ("hwmon: (pmbus/mpq8785) fix VOUT_MODE mismatch during identification") Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04Revert "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-01-08hwmon: (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-08hwmon: (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-08hwmon: (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-08hwmon: (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-08hwmon: (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-08hwmon: (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-08hwmon: (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-08hwmon: (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-13hwmon: (dell-smm) Remove Dell Precision 490 custom config dataArmin Wolf1-14/+0
[ Upstream commit ddb61e737f04e3c6c8299c1e00bf17a42a7f05cf ] It turns out the second fan on the Dell Precision 490 does not really support I8K_FAN_TURBO. Setting the fan state to 3 enables automatic fan control, just like on the other two fans. The reason why this was misinterpreted as turbo mode was that the second fan normally spins faster in automatic mode than in the previous fan states. Yet when in state 3, the fan speed reacts to heat exposure, exposing the automatic mode setting. Link: https://github.com/lm-sensors/lm-sensors/pull/383 Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250917181036.10972-2-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-13hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutexBen Copeland1-1/+1
[ Upstream commit 584d55be66ef151e6ef9ccb3dcbc0a2155559be1 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-13hwmon: sy7636a: add aliasAndreas Kemnade1-0/+1
[ Upstream commit 80038a758b7fc0cdb6987532cbbf3f75b13e0826 ] Add module alias to have it autoloaded. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20250909080249.30656-1-andreas@kemnade.info Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-13hwmon: (sbtsi_temp) AMD CPU extended temperature range supportChuande Chen1-15/+31
[ Upstream commit d9d61f1da35038793156c04bb13f0a1350709121 ] Many AMD CPUs can support this feature now. We would get a wrong CPU DIE temperature if don't consider this. In low-temperature environments, the CPU die temperature can drop below zero. So many platforms would like to make extended temperature range as their default configuration. Default temperature range (0C to 255.875C). Extended temperature range (-49C to +206.875C). Ref Doc: AMD V3000 PPR (Doc ID #56558). Signed-off-by: Chuande Chen <chuachen@cisco.com> Link: https://lore.kernel.org/r/20250814053940.96764-1-chenchuande@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-13hwmon: (lenovo-ec-sensors) Update P8 supprtDavid Ober1-4/+30
[ Upstream commit 43c056ac85b60232861005765153707f1b0354b6 ] This fixes differences for the P8 system that was initially set to the same thermal values as the P7, also adds in the PSU sensor for all of the supported systems Signed-off-by: David Ober <dober@lenovo.com> Signed-off-by: David Ober <dober6023@gmail.com> Link: https://lore.kernel.org/r/20250807103228.10465-1-dober6023@gmail.com [groeck: Update subject] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-13hwmon: (k10temp) Add device ID for Strix HaloRong Zhang1-0/+1
[ Upstream commit e5d1e313d7b6272d6dfda983906d99f97ad9062b ] The device ID of Strix Halo Data Fabric Function 3 has been in the tree since commit 0e640f0a47d8 ("x86/amd_nb: Add new PCI IDs for AMD family 0x1a"), but is somehow missing from k10temp_id_table. Add it so that it works out of the box. Tested on Beelink GTR9 Pro Mini PC. Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250823180443.85512-1-i@rong.moe Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-13hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based modelsAvadhut Naik1-0/+9
[ Upstream commit f116af2eb51ed9df24911537fda32a033f1c58da ] Add thermal info support for newer AMD Family 1Ah-based models. Signed-off-by: Avadhut Naik <avadhut.naik@amd.com> Link: https://lore.kernel.org/r/20250729001644.257645-1-avadhut.naik@amd.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-29hwmon: (sht3x) Fix error handlingGuenter Roeck1-10/+17
[ Upstream commit 8dcc66ad379ec0642fb281c45ccfd7d2d366e53f ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-15hwmon: (mlxreg-fan) Separate methods of fan setting coming from different ↵Vadim Pasternak1-8/+16
subsystems [ Upstream commit c02e4644f8ac9c501077ef5ac53ae7fc51472d49 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-09-09hwmon: mlxreg-fan: Prevent fans from getting stuck at 0 RPMVadim Pasternak1-3/+2
[ Upstream commit 1180c79fbf36e4c02e76ae4658509523437e52a4 ] The fans controlled by the driver can get stuck at 0 RPM if they are configured below a 20% duty cycle. The driver tries to avoid this by enforcing a minimum duty cycle of 20%, but this is done after the fans are registered with the thermal subsystem. This is too late as the thermal subsystem can set their current state before the driver is able to enforce the minimum duty cycle. Fix by setting the minimum duty cycle before registering the fans with the thermal subsystem. Fixes: d7efb2ebc7b3 ("hwmon: (mlxreg-fan) Extend driver to support multiply cooling devices") Reported-by: Nikolay Aleksandrov <razor@blackwall.org> Tested-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20250730201715.1111133-1-vadimp@nvidia.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28hwmon: (gsc-hwmon) fix fan pwm setpoint show functionsTim Harvey1-2/+2
commit 9c62e2282900332c8b711d9f9e37af369a8ef71b upstream. The Linux hwmon sysfs API values for pwmX_auto_pointY_pwm represent an integer value between 0 (0%) to 255 (100%) and the pwmX_auto_pointY_temp represent millidegrees Celcius. Commit a6d80df47ee2 ("hwmon: (gsc-hwmon) fix fan pwm temperature scaling") properly addressed the incorrect scaling in the pwm_auto_point_temp_store implementation but erroneously scaled the pwm_auto_point_pwm_show (pwm value) instead of the pwm_auto_point_temp_show (temp value) resulting in: # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_pwm 25500 # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_temp 4500 Fix the scaling of these attributes: # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_pwm 255 # cat /sys/class/hwmon/hwmon0/pwm1_auto_point6_temp 45000 Fixes: a6d80df47ee2 ("hwmon: (gsc-hwmon) fix fan pwm temperature scaling") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey <tharvey@gateworks.com> Link: https://lore.kernel.org/r/20250718200259.1840792-1-tharvey@gateworks.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-20hwmon: (emc2305) Set initial PWM minimum value during probe based on thermal ↵Florin Leotescu1-2/+8
state [ Upstream commit 0429415a084a15466e87d504e8c2a502488184a5 ] Prevent the PWM value from being set to minimum when thermal zone temperature exceeds any trip point during driver probe. Otherwise, the PWM fan speed will remains at minimum speed and not respond to temperature changes. Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com> Link: https://lore.kernel.org/r/20250603113125.3175103-5-florin.leotescu@oss.nxp.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-24hwmon: (corsair-cpro) Validate the size of the received input bufferMarius Zachmann1-0/+5
[ Upstream commit 495a4f0dce9c8c4478c242209748f1ee9e4d5820 ] Add buffer_recv_size to store the size of the received bytes. Validate buffer_recv_size in send_usb_cmd(). Reported-by: syzbot+3bbbade4e1a7ab45ca3b@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-hwmon/61233ba1-e5ad-4d7a-ba31-3b5d0adcffcc@roeck-us.net Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Marius Zachmann <mail@mariuszachmann.de> Link: https://lore.kernel.org/r/20250619132817.39764-5-mail@mariuszachmann.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-06hwmon: (pmbus/max34440) Fix support for max34451Alexis Czezar Torreno1-4/+44
[ Upstream commit 19932f844f3f51646f762f3eac4744ec3a405064 ] The max344** family has an issue with some PMBUS address being switched. This includes max34451 however version MAX34451-NA6 and later has this issue fixed and this commit supports that update. Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com> Link: https://lore.kernel.org/r/20250407-dev_adpm12160-v3-1-9cd3095445c8@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27hwmon: (ltc4282) avoid repeated register writeNuno Sá1-7/+0
[ Upstream commit c25892b7a1744355e16281cd24a9b59ec15ec974 ] The fault enabled bits were being mistankenly enabled twice in case the FW property is present. Remove one of the writes. Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20250611-fix-ltc4282-repetead-write-v1-1-fe46edd08cf1@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27hwmon: (occ) fix unaligned accessesArnd Bergmann1-15/+13
[ Upstream commit 2c021b45c154958566aad0cae9f74ab26a2d5732 ] Passing a pointer to an unaligned integer as a function argument is undefined behavior: drivers/hwmon/occ/common.c:492:27: warning: taking address of packed member 'accumulator' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 492 | val = occ_get_powr_avg(&power->accumulator, | ^~~~~~~~~~~~~~~~~~ drivers/hwmon/occ/common.c:493:13: warning: taking address of packed member 'update_tag' of class or structure 'power_sensor_2' may result in an unaligned pointer value [-Waddress-of-packed-member] 493 | &power->update_tag); | ^~~~~~~~~~~~~~~~~ Move the get_unaligned() calls out of the function and pass these through argument registers instead. Fixes: c10e753d43eb ("hwmon (occ): Add sensor types and versions") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250610092553.2641094-1-arnd@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27hwmon: (occ) Rework attribute registration for stack usageArnd Bergmann1-127/+85
[ Upstream commit 744c2fe950e936c4d62430de899d6253424200ed ] clang produces an output with excessive stack usage when building the occ_setup_sensor_attrs() function, apparently the result of having a lot of struct literals and building with the -fno-strict-overflow option that leads clang to skip some optimization in case the 'attr' pointer overruns: drivers/hwmon/occ/common.c:775:12: error: stack frame size (1392) exceeds limit (1280) in 'occ_setup_sensor_attrs' [-Werror,-Wframe-larger-than] Replace the custom macros for initializing the attributes with a simpler function call that does not run into this corner case. Link: https://godbolt.org/z/Wf1Yx76a5 Fixes: 54076cb3b5ff ("hwmon (occ): Add sensor attributes and register hwmon device") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250610092315.2640039-1-arnd@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27hwmon: (ftsteutates) Fix TOCTOU race in fts_read()Gui-Dong Han1-3/+6
commit 14c9ede9ca4cd078ad76a6ab9617b81074eb58bf upstream. In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team. Fixes: 1c5759d8ce05 ("hwmon: (ftsteutates) Replace fanX_source with pwmX_auto_channels_temp") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Link: https://lore.kernel.org/r/20250606071640.501262-1-hanguidong02@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19hwmon: (asus-ec-sensors) check sensor index in read_string()Alexei Safin1-0/+4
[ Upstream commit 25be318324563c63cbd9cb53186203a08d2f83a1 ] Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d0ddfd241e57 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Alexei Safin <a.safin@rosa.ru> Link: https://lore.kernel.org/r/20250424202654.5902-1-a.safin@rosa.ru [groeck: Return error code returned from find_ec_sensor_index] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29hwmon: (xgene-hwmon) use appropriate type for the latency valueAndrey Vatoropin1-1/+1
[ Upstream commit 8df0f002827e18632dcd986f7546c1abf1953a6f ] The expression PCC_NUM_RETRIES * pcc_chan->latency is currently being evaluated using 32-bit arithmetic. Since a value of type 'u64' is used to store the eventual result, and this result is later sent to the function usecs_to_jiffies with input parameter unsigned int, the current data type is too wide to store the value of ctx->usecs_lat. Change the data type of "usecs_lat" to a more suitable (narrower) type. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Andrey Vatoropin <a.vatoropin@crpt.ru> Link: https://lore.kernel.org/r/20250204095400.95013-1-a.vatoropin@crpt.ru Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29hwmon: (gpio-fan) Add missing mutex locksAlexander Stein1-1/+15
[ Upstream commit 9fee7d19bab635f89223cc40dfd2c8797fdc4988 ] set_fan_speed() is expected to be called with fan_data->lock being locked. Add locking for proper synchronization. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20250210145934.761280-3-alexander.stein@ew.tq-group.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-29hwmon: (dell-smm) Increment the number of fansKurt Borja1-1/+4
[ Upstream commit dbcfcb239b3b452ef8782842c36fb17dd1b9092f ] Some Alienware laptops that support the SMM interface, may have up to 4 fans. Tested on an Alienware x15 r1. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250304055249.51940-2-kuurtb@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-29 00:18:05 +0300