summaryrefslogtreecommitdiff
path: root/drivers/hwmon
AgeCommit message (Collapse)AuthorFilesLines
5 dayshwmon: (max16065) Use local variable to avoid TOCTOUGui-Dong Han1-3/+4
[ Upstream commit b8d5acdcf525f44e521ca4ef51dce4dac403dab4 ] 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: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5 dayshwmon: replace snprintf in show functions with sysfs_emitGuenter Roeck24-150/+151
[ Upstream commit 1f4d4af4d7a1c794a4f003f75fcfd38fafb5dff3 ] coccicheck complains about the use of snprintf() in sysfs show functions. drivers/hwmon/ina3221.c:701:8-16: WARNING: use scnprintf or sprintf This results in a large number of patch submissions. Fix it all in one go using the following coccinelle rules. Use sysfs_emit instead of scnprintf or sprintf since that makes more sense. @depends on patch@ identifier show, dev, attr, buf; @@ ssize_t show(struct device *dev, struct device_attribute *attr, char *buf) { <... return - snprintf(buf, \( PAGE_SIZE \| PAGE_SIZE - 1 \), + sysfs_emit(buf, ...); ...> } @depends on patch@ identifier show, dev, attr, buf, rc; @@ ssize_t show(struct device *dev, struct device_attribute *attr, char *buf) { <... rc = - snprintf(buf, \( PAGE_SIZE \| PAGE_SIZE - 1 \), + sysfs_emit(buf, ...); ...> } While at it, remove unnecessary braces and as well as unnecessary else after return statements to address checkpatch warnings in the resulting patch. Cc: Zihao Tang <tangzihao1@hisilicon.com> Cc: Jay Fang <f.fangjian@huawei.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: b8d5acdcf525 ("hwmon: (max16065) Use local variable to avoid TOCTOU") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5 dayshwmon: (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>
5 dayshwmon: (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>
5 dayshwmon: (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>
2025-12-07hwmon: (dell-smm) Add support for Dell OptiPlex 7040Armin Wolf1-0/+7
[ Upstream commit 53d3bd48ef6ff1567a75ca77728968f5ab493cb4 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-29minmax: make generic MIN() and MAX() macros available everywhereLinus Torvalds1-12/+12
[ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ] This just standardizes the use of MIN() and MAX() macros, with the very traditional semantics. The goal is to use these for C constant expressions and for top-level / static initializers, and so be able to simplify the min()/max() macros. These macro names were used by various kernel code - they are very traditional, after all - and all such users have been fixed up, with a few different approaches: - trivial duplicated macro definitions have been removed Note that 'trivial' here means that it's obviously kernel code that already included all the major kernel headers, and thus gets the new generic MIN/MAX macros automatically. - non-trivial duplicated macro definitions are guarded with #ifndef This is the "yes, they define their own versions, but no, the include situation is not entirely obvious, and maybe they don't get the generic version automatically" case. - strange use case #1 A couple of drivers decided that the way they want to describe their versioning is with #define MAJ 1 #define MIN 2 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) which adds zero value and I just did my Alexander the Great impersonation, and rewrote that pointless Gordian knot as #define DRV_VERSION "1.2" instead. - strange use case #2 A couple of drivers thought that it's a good idea to have a random 'MIN' or 'MAX' define for a value or index into a table, rather than the traditional macro that takes arguments. These values were re-written as C enum's instead. The new function-line macros only expand when followed by an open parenthesis, and thus don't clash with enum use. Happily, there weren't really all that many of these cases, and a lot of users already had the pattern of using '#ifndef' guarding (or in one case just using '#undef MIN') before defining their own private version that does the same thing. I left such cases alone. Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Eliav Farber <farbere@amazon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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-28hwmon: (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-17hwmon: (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: (occ) Fix P10 VRM temp sensorsEddie James1-12/+5
commit ffa2600044979aff4bd6238edb9af815a47d7c32 upstream. The P10 (temp sensor version 0x10) doesn't do the same VRM status reporting that was used on P9. It just reports the temperature, so drop the check for VRM fru type in the sysfs show function, and don't set the name to "alarm". Fixes: db4919ec86 ("hwmon: (occ) Add new temperature sensor type") Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20210929153604.14968-1-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: (occ) Add soft minimum power cap attributeEddie James1-3/+16
[ Upstream commit 84dc9e8a7eec2cdff00728baedf0fb35fc7c11e8 ] Export the power caps data for the soft minimum power cap through hwmon. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20220215151022.7498-5-eajames@linux.ibm.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 744c2fe950e9 ("hwmon: (occ) Rework attribute registration for stack usage") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27hwmon: (occ) Add new temperature sensor typeEddie James1-0/+75
[ Upstream commit db4919ec86ff405273a767e1a9b51e2760e73ce5 ] The latest version of the On-Chip Controller (OCC) has a different format for the temperature sensor data. Add a new temperature sensor version to handle this data. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201120010315.190737-4-joel@jms.id.au Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 744c2fe950e9 ("hwmon: (occ) Rework attribute registration for stack usage") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04hwmon: (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-06-04hwmon: (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-04-10hwmon: (nct6775-core) Fix out of bounds access for NCT679{8,9}Tasos Sahanidis1-2/+2
[ Upstream commit 815f80ad20b63830949a77c816e35395d5d55144 ] pwm_num is set to 7 for these chips, but NCT6776_REG_PWM_MODE and NCT6776_PWM_MODE_MASK only contain 6 values. Fix this by adding another 0 to the end of each array. Signed-off-by: Tasos Sahanidis <tasos@tasossah.com> Link: https://lore.kernel.org/r/20250312030832.106475-1-tasos@tasossah.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13hwmon: fix a NULL vs IS_ERR_OR_NULL() check in xgene_hwmon_probe()Xinghuo Chen1-1/+1
[ Upstream commit 10fce7ebe888fa8c97eee7e317a47e7603e5e78d ] The devm_memremap() function returns error pointers on error, it doesn't return NULL. Fixes: c7cefce03e69 ("hwmon: (xgene) access mailbox as RAM") Signed-off-by: Xinghuo Chen <xinghuo.chen@foxmail.com> Link: https://lore.kernel.org/r/tencent_9AD8E7683EC29CAC97496B44F3F865BA070A@qq.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13hwmon: (ad7314) Validate leading zero bits and return errorErik Schumacher1-0/+10
[ Upstream commit e278d5e8aef4c0a1d9a9fa8b8910d713a89aa800 ] Leading zero bits are sent on the bus before the temperature value is transmitted. If any of these bits are high, the connection might be unstable or there could be no AD7314 / ADT730x (or compatible) at all. Return -EIO in that case. Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com> Fixes: 4f3a659581cab ("hwmon: AD7314 driver (ported from IIO)") Link: https://lore.kernel.org/r/24a50c2981a318580aca8f50d23be7987b69ea00.camel@iris-sensing.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor tableMaud Spierings1-33/+33
[ Upstream commit 1c7932d5ae0f5c22fa52ac811b4c427bbca5aff5 ] I could not find a single table that has the values currently present in the table, change it to the actual values that can be found in [1]/[2] and [3] (page 15 column 2) [1]: https://www.murata.com/products/productdetail?partno=NCP15XH103F03RC [2]: https://www.murata.com/products/productdata/8796836626462/NTHCG83.txt?1437969843000 [3]: https://nl.mouser.com/datasheet/2/281/r44e-522712.pdf Fixes: 54ce3a0d8011 ("hwmon: (ntc_thermistor) Add support for ncpXXxh103") Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Link: https://lore.kernel.org/r/20250227-ntc_thermistor_fixes-v1-3-70fa73200b52@gocontroll.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13hwmon: (pmbus) Initialise page count in pmbus_identify()Titus Rwantare1-0/+2
[ Upstream commit 6b6e2e8fd0de3fa7c6f4f8fe6841b01770b2e7bc ] The `pmbus_identify()` function fails to correctly determine the number of supported pages on PMBus devices. This occurs because `info->pages` is implicitly zero-initialised, and `pmbus_set_page()` does not perform writes to the page register if `info->pages` is not yet initialised. Without this patch, `info->pages` is always set to the maximum after scanning. This patch initialises `info->pages` to `PMBUS_PAGES` before the probing loop, enabling `pmbus_set_page()` writes to make it out onto the bus correctly identifying the number of pages. `PMBUS_PAGES` seemed like a reasonable non-zero number because that's the current result of the identification process. Testing was done with a PMBus device in QEMU. Signed-off-by: Titus Rwantare <titusr@google.com> Fixes: 442aba78728e7 ("hwmon: PMBus device driver") Link: https://lore.kernel.org/r/20250227222455.2583468-1-titusr@google.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-09hwmon: (tmp513) Fix interpretation of values of Temperature Result and Limit ↵Murad Masimov1-1/+1
Registers [ Upstream commit dd471e25770e7e632f736b90db1e2080b2171668 ] The values returned by the driver after processing the contents of the Temperature Result and the Temperature Limit Registers do not correspond to the TMP512/TMP513 specifications. A raw register value is converted to a signed integer value by a sign extension in accordance with the algorithm provided in the specification, but due to the off-by-one error in the sign bit index, the result is incorrect. According to the TMP512 and TMP513 datasheets, the Temperature Result (08h to 0Bh) and Limit (11h to 14h) Registers are 13-bit two's complement integer values, shifted left by 3 bits. The value is scaled by 0.0625 degrees Celsius per bit. E.g., if regval = 1 1110 0111 0000 000, the output should be -25 degrees, but the driver will return +487 degrees. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 59dfa75e5d82 ("hwmon: Add driver for Texas Instruments TMP512/513 sensor chips.") Signed-off-by: Murad Masimov <m.masimov@maxima.ru> Link: https://lore.kernel.org/r/20241216173648.526-4-m.masimov@maxima.ru [groeck: fixed description line length] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (adm9240) Add missing dependency on REGMAP_I2CJavier Carrasco1-0/+1
[ Upstream commit 14849a2ec175bb8a2280ce20efe002bb19f1e274 ] This driver requires REGMAP_I2C to be selected in order to get access to regmap_config and devm_regmap_init_i2c. Add the missing dependency. Fixes: df885d912f67 ("hwmon: (adm9240) Convert to regmap") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Message-ID: <20241002-hwmon-select-regmap-v1-1-548d03268934@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (tmp513) Add missing dependency on REGMAP_I2CGuenter Roeck1-0/+1
[ Upstream commit 193bc02c664999581a1f38c152f379fce91afc0c ] 0-day reports: drivers/hwmon/tmp513.c:162:21: error: variable 'tmp51x_regmap_config' has initializer but incomplete type 162 | static const struct regmap_config tmp51x_regmap_config = { | ^ struct regmap_config is only available if REGMAP is enabled. Add the missing Kconfig dependency to fix the problem. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410020246.2cTDDx0X-lkp@intel.com/ Fixes: 59dfa75e5d82 ("hwmon: Add driver for Texas Instruments TMP512/513 sensor chips.") Cc: Eric Tremblay <etremblay@distech-controls.com> Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (ntc_thermistor) fix module autoloadingYuntao Liu1-0/+1
[ Upstream commit b6964d66a07a9003868e428a956949e17ab44d7e ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Fixes: 9e8269de100d ("hwmon: (ntc_thermistor) Add DT with IIO support to NTC thermistor driver") Signed-off-by: Yuntao Liu <liuyuntao12@huawei.com> Message-ID: <20240815083021.756134-1-liuyuntao12@huawei.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (max16065) Fix alarm attributesGuenter Roeck1-2/+10
[ Upstream commit 119abf7d1815f098f7f91ae7abc84324a19943d7 ] Chips reporting overcurrent alarms report it in the second alarm register. That means the second alarm register has to be read, even if the chip only supports 8 or fewer ADC channels. MAX16067 and MAX16068 report undervoltage and overvoltage alarms in separate registers. Fold register contents together to report both with the existing alarm attribute. This requires actually storing the chip type in struct max16065_data. Rename the variable 'chip' to match the variable name used in the probe function. Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (max16065) Remove use of i2c_match_id()Andrew Davis1-6/+4
[ Upstream commit 5a71654b398e3471f0169c266a3587cf09e1200c ] The function i2c_match_id() is used to fetch the matching ID from the i2c_device_id table. This is often used to then retrieve the matching driver_data. This can be done in one step with the helper i2c_get_match_data(). This helper has a couple other benefits: * It doesn't need the i2c_device_id passed in so we do not need to have that forward declared, allowing us to remove those or move the i2c_device_id table down to its more natural spot with the other module info. * It also checks for device match data, which allows for OF and ACPI based probing. That means we do not have to manually check those first and can remove those checks. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240403203633.914389-20-afd@ti.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 119abf7d1815 ("hwmon: (max16065) Fix alarm attributes") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (max16065) Fix overflows seen when writing limitsGuenter Roeck1-2/+3
[ Upstream commit 744ec4477b11c42e2c8de9eb8364675ae7a0bd81 ] Writing large limits resulted in overflows as reported by module tests. in0_lcrit: Suspected overflow: [max=5538, read 0, written 2147483647] in0_crit: Suspected overflow: [max=5538, read 0, written 2147483647] in0_min: Suspected overflow: [max=5538, read 0, written 2147483647] Fix the problem by clamping prior to multiplications and the use of DIV_ROUND_CLOSEST, and by using consistent variable types. Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Fixes: f5bae2642e3d ("hwmon: Driver for MAX16065 System Manager and compatibles") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (pmbus) Conditionally clear individual status bits for pmbus rev >= 1.2Patryk Biel2-3/+20
[ Upstream commit 20471071f198c8626dbe3951ac9834055b387844 ] The current implementation of pmbus_show_boolean assumes that all devices support write-back operation of status register to clear pending warnings or faults. Since clearing individual bits in the status registers was only introduced in PMBus specification 1.2, this operation may not be supported by some older devices. This can result in an error while reading boolean attributes such as temp1_max_alarm. Fetch PMBus revision supported by the device and modify pmbus_show_boolean so that it only tries to clear individual status bits if the device is compliant with PMBus specs >= 1.2. Otherwise clear all fault indicators on the current page after a fault status was reported. Fixes: 35f165f08950a ("hwmon: (pmbus) Clear pmbus fault/warning bits after read") Signed-off-by: Patryk Biel <pbiel7@gmail.com> Message-ID: <20240909-pmbus-status-reg-clearing-v1-1-f1c0d68c6408@gmail.com> [groeck: Rewrote description Moved revision detection code ahead of clear faults command Assigned revision if return value from PMBUS_REVISION command is 0 Improved return value check from calling _pmbus_write_byte_data()] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17hwmon: (pmbus) Introduce and use write_byte_data callbackMårten Lindahl2-3/+23
[ Upstream commit 5de3e13f7f6b496bd7bd9ff4d2b915b7d3e67cda ] Some of the pmbus core functions uses pmbus_write_byte_data, which does not support driver callbacks for chip specific write operations. This could potentially influence some specific regulator chips that for example need a time delay before each data access. Lets add support for driver callback with _pmbus_write_byte_data. Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20220428144039.2464667-2-marten.lindahl@axis.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 20471071f198 ("hwmon: (pmbus) Conditionally clear individual status bits for pmbus rev >= 1.2") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-12hwmon: (w83627ehf) Fix underflows seen when writing limit attributesGuenter Roeck1-2/+2
[ Upstream commit 5c1de37969b7bc0abcb20b86e91e70caebbd4f89 ] DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-12hwmon: (nct6775-core) Fix underflows seen when writing limit attributesGuenter Roeck1-1/+1
[ Upstream commit 0403e10bf0824bf0ec2bb135d4cf1c0cc3bf4bf0 ] DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-12hwmon: (lm95234) Fix underflows seen when writing limit attributesGuenter Roeck1-4/+5
[ Upstream commit af64e3e1537896337405f880c1e9ac1f8c0c6198 ] DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-12hwmon: (adc128d818) Fix underflows seen when writing limit attributesGuenter Roeck1-2/+2
[ Upstream commit 8cad724c8537fe3e0da8004646abc00290adae40 ] DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-19hwmon: (max6697) Fix swapped temp{1,8} critical alarmsGuenter Roeck1-2/+2
[ Upstream commit 1ea3fd1eb9869fcdcbc9c68f9728bfc47b9503f1 ] The critical alarm bit for the local temperature sensor (temp1) is in bit 7 of register 0x45 (not bit 6), and the critical alarm bit for remote temperature sensor 7 (temp8) is in bit 6 (not bit 7). This only affects MAX6581 since all other chips supported by this driver do not support those critical alarms. Fixes: 5372d2d71c46 ("hwmon: Driver for Maxim MAX6697 and compatibles") Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-19hwmon: (max6697) Fix underflow when writing limit attributesGuenter Roeck1-0/+1
[ Upstream commit cbf7467828cd4ec7ceac7a8b5b5ddb2f69f07b0e ] Using DIV_ROUND_CLOSEST() on an unbound value can result in underflows. Indeed, module test scripts report: temp1_max: Suspected underflow: [min=0, read 255000, written -9223372036854775808] temp1_crit: Suspected underflow: [min=0, read 255000, written -9223372036854775808] Fix by introducing an extra set of clamping. Fixes: 5372d2d71c46 ("hwmon: Driver for Maxim MAX6697 and compatibles") Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-19hwmon: (adt7475) Fix default duty on fan is disabledWayne Tung1-1/+1
[ Upstream commit 39b24cced70fdc336dbc0070f8b3bde61d8513a8 ] According to the comments on fan is disabled, we change to manual mode and set the duty cycle to 0. For setting the duty cycle part, the register is wrong. Fix it. Fixes: 1c301fc5394f ("hwmon: Add a driver for the ADT7475 hardware monitoring chip") Signed-off-by: Wayne Tung <chineweff@gmail.com> Link: https://lore.kernel.org/r/20240701073252.317397-1-chineweff@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-16hwmon: (shtc1) Fix property misspellingGuenter Roeck1-1/+1
[ Upstream commit 52a2c70c3ec555e670a34dd1ab958986451d2dd2 ] The property name is "sensirion,low-precision", not "sensicon,low-precision". Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk> Fixes: be7373b60df5 ("hwmon: shtc1: add support for device tree bindings") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17hwmon: (pmbus/ucd9000) Increase delay from 250 to 500usLakshmi Yadlapati1-3/+3
commit 26e8383b116d0dbe74e28f86646563ab46d66d83 upstream. Following the failure observed with a delay of 250us, experiments were conducted with various delays. It was found that a delay of 350us effectively mitigated the issue. To provide a more optimal solution while still allowing a margin for stability, the delay is being adjusted to 500us. Signed-off-by: Lakshmi Yadlapati <lakshmiy@us.ibm.com> Link: https://lore.kernel.org/r/20240507194603.1305750-1-lakshmiy@us.ibm.com Fixes: 8d655e6523764 ("hwmon: (ucd90320) Add minimum delay between bus accesses") Reviewed-by: Eddie James <eajames@linux.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-17hwmon: (corsair-cpro) Protect ccp->wait_input_report with a spinlockAleksa Savic1-5/+19
[ Upstream commit d02abd57e79469a026213f7f5827a98d909f236a ] Through hidraw, userspace can cause a status report to be sent from the device. The parsing in ccp_raw_event() may happen in parallel to a send_usb_cmd() call (which resets the completion for tracking the report) if it's running on a different CPU where bottom half interrupts are not disabled. Add a spinlock around the complete_all() in ccp_raw_event() and reinit_completion() in send_usb_cmd() to prevent race issues. Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com> Acked-by: Marius Zachmann <mail@mariuszachmann.de> Link: https://lore.kernel.org/r/20240504092504.24158-4-savicaleksa83@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17hwmon: (corsair-cpro) Use complete_all() instead of complete() in ↵Aleksa Savic1-1/+1
ccp_raw_event() [ Upstream commit 3a034a7b0715eb51124a5263890b1ed39978ed3a ] In ccp_raw_event(), the ccp->wait_input_report completion is completed once. Since we're waiting for exactly one report in send_usb_cmd(), use complete_all() instead of complete() to mark the completion as spent. Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com> Acked-by: Marius Zachmann <mail@mariuszachmann.de> Link: https://lore.kernel.org/r/20240504092504.24158-3-savicaleksa83@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-05-17hwmon: (corsair-cpro) Use a separate buffer for sending commandsAleksa Savic1-7/+12
[ Upstream commit e0cd85dc666cb08e1bd313d560cb4eff4d04219e ] Introduce cmd_buffer, a separate buffer for storing only the command that is sent to the device. Before this separation, the existing buffer was shared for both the command and the report received in ccp_raw_event(), which was copied into it. However, because of hidraw, the raw event parsing may be triggered in the middle of sending a command, resulting in outputting gibberish to the device. Using a separate buffer resolves this. Fixes: 40c3a4454225 ("hwmon: add Corsair Commander Pro driver") Signed-off-by: Aleksa Savic <savicaleksa83@gmail.com> Acked-by: Marius Zachmann <mail@mariuszachmann.de> Link: https://lore.kernel.org/r/20240504092504.24158-2-savicaleksa83@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13hwmon: (amc6821) add of_match tableJosua Mayer1-0/+11
[ Upstream commit 3f003fda98a7a8d5f399057d92e6ed56b468657c ] Add of_match table for "ti,amc6821" compatible string. This fixes automatic driver loading by userspace when using device-tree, and if built as a module like major linux distributions do. While devices probe just fine with i2c_device_id table, userspace can't match the "ti,amc6821" compatible string from dt with the plain "amc6821" device id. As a result, the kernel module can not be loaded. Cc: stable@vger.kernel.org Signed-off-by: Josua Mayer <josua@solid-run.com> Link: https://lore.kernel.org/r/20240307-amc6821-of-match-v1-1-5f40464a3110@solid-run.com [groeck: Cleaned up patch description] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-01hwmon: (coretemp) Enlarge per package core count limitZhang Rui1-1/+1
[ Upstream commit 34cf8c657cf0365791cdc658ddbca9cc907726ce ] Currently, coretemp driver supports only 128 cores per package. This loses some core temperature information on systems that have more than 128 cores per package. [ 58.685033] coretemp coretemp.0: Adding Core 128 failed [ 58.692009] coretemp coretemp.0: Adding Core 129 failed ... Enlarge the limitation to 512 because there are platforms with more than 256 cores per package. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20240202092144.71180-4-rui.zhang@intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23hwmon: (coretemp) Fix bogus core_id to attr name mappingZhang Rui1-13/+19
[ Upstream commit fdaf0c8629d4524a168cb9e4ad4231875749b28c ] Before commit 7108b80a542b ("hwmon/coretemp: Handle large core ID value"), there is a fixed mapping between 1. cpu_core_id 2. the index in pdata->core_data[] array 3. the sysfs attr name, aka "tempX_" The later two always equal cpu_core_id + 2. After the commit, pdata->core_data[] index is got from ida so that it can handle sparse core ids and support more cores within a package. However, the commit erroneously maps the sysfs attr name to pdata->core_data[] index instead of cpu_core_id + 2. As a result, the code is not aligned with the comments, and brings user visible changes in hwmon sysfs on systems with sparse core id. For example, before commit 7108b80a542b ("hwmon/coretemp: Handle large core ID value"), /sys/class/hwmon/hwmon2/temp2_label:Core 0 /sys/class/hwmon/hwmon2/temp3_label:Core 1 /sys/class/hwmon/hwmon2/temp4_label:Core 2 /sys/class/hwmon/hwmon2/temp5_label:Core 3 /sys/class/hwmon/hwmon2/temp6_label:Core 4 /sys/class/hwmon/hwmon3/temp10_label:Core 8 /sys/class/hwmon/hwmon3/temp11_label:Core 9 after commit, /sys/class/hwmon/hwmon2/temp2_label:Core 0 /sys/class/hwmon/hwmon2/temp3_label:Core 1 /sys/class/hwmon/hwmon2/temp4_label:Core 2 /sys/class/hwmon/hwmon2/temp5_label:Core 3 /sys/class/hwmon/hwmon2/temp6_label:Core 4 /sys/class/hwmon/hwmon2/temp7_label:Core 8 /sys/class/hwmon/hwmon2/temp8_label:Core 9 Restore the previous behavior and rework the code, comments and variable names to avoid future confusions. Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Link: https://lore.kernel.org/r/20240202092144.71180-3-rui.zhang@intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23hwmon: (coretemp) Fix out-of-bounds memory accessZhang Rui1-6/+2
[ Upstream commit 4e440abc894585a34c2904a32cd54af1742311b3 ] Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package. Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20240202092144.71180-2-rui.zhang@intel.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: fdaf0c8629d4 ("hwmon: (coretemp) Fix bogus core_id to attr name mapping") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-23hwmon: (aspeed-pwm-tacho) mutex for tach readingLoic Prylli1-0/+7
[ Upstream commit 1168491e7f53581ba7b6014a39a49cfbbb722feb ] the ASPEED_PTCR_RESULT Register can only hold the result for a single fan input. Adding a mutex to protect the register until the reading is done. Signed-off-by: Loic Prylli <lprylli@netflix.com> Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com> Fixes: 2d7a548a3eff ("drivers: hwmon: Support for ASPEED PWM/Fan tach") Link: https://lore.kernel.org/r/121d888762a1232ef403cf35230ccf7b3887083a.1699007401.git.alexander.hansen@9elements.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-13hwmon: (acpi_power_meter) Fix 4.29 MW bugArmin Wolf1-0/+4
[ Upstream commit 1fefca6c57fb928d2131ff365270cbf863d89c88 ] The ACPI specification says: "If an error occurs while obtaining the meter reading or if the value is not available then an Integer with all bits set is returned" Since the "integer" is 32 bits in case of the ACPI power meter, userspace will get a power reading of 2^32 * 1000 miliwatts (~4.29 MW) in case of such an error. This was discovered due to a lm_sensors bugreport (https://github.com/lm-sensors/lm-sensors/issues/460). Fix this by returning -ENODATA instead. Tested-by: <urbinek@gmail.com> Fixes: de584afa5e18 ("hwmon driver for ACPI 4.0 power meters") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20231124182747.13956-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20hwmon: (coretemp) Fix potentially truncated sysfs attribute nameZhang Rui1-1/+1
[ Upstream commit bbfff736d30e5283ad09e748caff979d75ddef7f ] When build with W=1 and "-Werror=format-truncation", below error is observed in coretemp driver, drivers/hwmon/coretemp.c: In function 'create_core_data': >> drivers/hwmon/coretemp.c:393:34: error: '%s' directive output may be truncated writing likely 5 or more bytes into a region of size between 3 and 13 [-Werror=format-truncation=] 393 | "temp%d_%s", attr_no, suffixes[i]); | ^~ drivers/hwmon/coretemp.c:393:26: note: assuming directive output of 5 bytes 393 | "temp%d_%s", attr_no, suffixes[i]); | ^~~~~~~~~~~ drivers/hwmon/coretemp.c:392:17: note: 'snprintf' output 7 or more bytes (assuming 22) into a destination of size 19 392 | snprintf(tdata->attr_name[i], CORETEMP_NAME_LENGTH, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 393 | "temp%d_%s", attr_no, suffixes[i]); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Given that 1. '%d' could take 10 charactors, 2. '%s' could take 10 charactors ("crit_alarm"), 3. "temp", "_" and the NULL terminator take 6 charactors, fix the problem by increasing CORETEMP_NAME_LENGTH to 28. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Fixes: 7108b80a542b ("hwmon/coretemp: Handle large core ID value") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310200443.iD3tUbbK-lkp@intel.com/ Link: https://lore.kernel.org/r/20231025122316.836400-1-rui.zhang@intel.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-01-24 19:57:46 +0300