- 27 Oct, 2023 36 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230918085951.1234172-25-u.kleine-koenig@pengutronix.deSigned-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230918085951.1234172-3-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The two drivers compile fine on arm64, powerpc, m68k and s390. So make it possible to enable the drivers in the presence of COMPILE_TEST. Signed-off-by:
-
Armin Wolf authored
The values of the limit registers affect the fan speed in a particular way. Document this behaviour so that future users can exploit it if required. Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20230907052639.16491-6-W_Armin@gmx.deSigned-off-by:
-
Armin Wolf authored
After some testing on a Fujitsu Esprimo P720, it turned out that the limit registers are indeed writable and affect the fan control algorithm. This is supported by the datasheet, which says that the fan control functions are based on the limit and parameter registers. Since accessing those registers is very inefficient, the existing regmap cache is used to cache those registers values. Tested on a Fujitsu Esprimo P720. Signed-off-by:
-
Armin Wolf authored
Accessing virtual registers is very inefficient, so pwm map values should be cached when possible, else userspace could effectively do a DOS attack by reading pwm map values in a while loop. Use the regmap cache to cache those values. Tested on a Fujitsu Esprimo P720. Signed-off-by:
-
Armin Wolf authored
When the lock bit inside SCH5627_REG_CTRL is set, then the virtual registers become read-only until the next power cycle. Disallow write access to those registers in such a case. Tested on a Fujitsu Esprimo P720. Fixes: aa9f833d ("hwmon: (sch5627) Add pwmX_auto_channels_temp support") Signed-off-by:
-
Armin Wolf authored
Use bit macros then accessing SCH5627_REG_CTRL, so that people do not need to look at the datasheet to find out what each bit does. Tested on a Fujitsu Esprimo P720. Signed-off-by:
-
Biju Das authored
Simplify tmp51x_read_properties() by replacing 'nfactor' ->'data->nfactor' in device_property_read_u32_array() and drop the local variable as it is unused. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230907071404.24334-3-biju.das.jz@bp.renesas.comSigned-off-by:
-
Biju Das authored
The tmp512 chip has 3 channels whereas tmp513 has 4 channels. Avoid using tmp51x_ids for this HW difference by replacing OF/ID table data with maximum channels supported by the device. Replace id->max_channels variable from struct tmp51x_data and drop the macros TMP51{2,3}_TEMP_CONFIG_DEFAULT as it can be derived from the macro TMP51X_TEMP_CONFIG_DEFAULT and update the logic in tmp51x_is_visible(), tmp51x_read_properties() and tmp51x_init() using max_channels. While at it, drop enum tmp51x_ids as there is no user and remove trailing comma in the terminator entry for OF table. Signed-off-by: -
Patrick Rudolph authored
TDA38640 can operate in either PMBus mode or SVID mode. In SVID mode, by design ENABLE pin is the only option for controlling the output rail i.e., ENABLE pin is chained to power good of another reglator & FPGA. In cases where the chip is configured for SVID mode, and the ENABLE pin is set at a fixed level or is left unconnected (with an internal pull-down), while requiring software control, the following workaround is necessary. The workaround utilizes ENABLE pin polarity flipping to control output rail. If property 'infineon,en-pin-fixed-level' is specified then determine if chip is in SVID mode by checking BIT15 of MTP memory offset 0x44 as described in the datasheet. If chip is in SVID mode then apply the workaround by 1. Determine EN pin level 2. Maps BIT7 of OPERATION(01h) to EN_PIN_POLARITY(BIT1) of PB_ON_OFF_CONFIG. Signed-off-by:
Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by:
Naresh Solanki <Naresh.Solanki@9elements.com> Link: https://lore.kernel.org/r/20230831190731.265099-3-Naresh.Solanki@9elements.com [groeck: Dropped unnecessary line continuation] Signed-off-by:
-
Patrick Rudolph authored
Add bits found in the ON_OFF_CONFIG register. Signed-off-by:
-
Patrick Rudolph authored
Add the DT property 'infineon,en-pin-fixed-level' to indicated that the chip EN pin is at fixed level or left unconnected(has internal pull-down). Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230831190731.265099-1-Naresh.Solanki@9elements.com [groeck: Dropped empty line at end] Signed-off-by:
-
Thomas Weißschuh authored
POWER-Z is a series of devices to monitor power characteristics of USB-C connections and display those on a on-device display. Some of the devices, notably KM002C and KM003C, contain an additional port which exposes the measurements via USB. This is a driver for this monitor port. It was developed and tested with the KM003C. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230902-powerz-v4-1-7ec2c1440687@weissschuh.net [groeck: Release urb after hwmon registration error; Move priv->status initialization to correct place before reinit_completion ] Signed-off-by:
-
Naresh Solanki authored
The PGOOD fix was intended for MP2973 & MP2971 & not for MP2975. Fixes: acda945a ("hwmon: (pmbus/mp2975) Fix PGOOD in READ_STATUS_WORD") Signed-off-by:
-
- 25 Oct, 2023 4 commits
-
-
Guenter Roeck authored
This reverts commit 393935ba. As reported by Ian Nartowicz, this and the next patch result in a failure to load the driver on Celsius W280. While the alternative would be to add the board to the DMI override table, it is quite likely that other systems are also affected. Revert the offending patches to avoid future problems. Fixes: 393935ba ("hwmon: (sch56xx-common) Add automatic module loading on supported devices") Reported-by:
Ian Nartowicz <deadbeef@nartowicz.co.uk> Closes: https://lore.kernel.org/linux-hwmon/20231025192239.3c5389ae@debian.org/T/#t Cc: Armin Wolf <W_Armin@gmx.de> Signed-off-by:
-
Guenter Roeck authored
This reverts commit fd2d53c3. As reported by Ian Nartowicz, this and the preceding patch result in a failure to load the driver on Celsius W280. While the alternative would be to add the board to the DMI override table, it is quite likely that other systems are also affected. Revert the offending patches to avoid future problems. Fixes: fd2d53c3 ("hwmon: (sch56xx-common) Add DMI override table") Reported-by:
-
Zev Weiss authored
In the regmap conversion in commit 4ef27745 ("hwmon: (nct6775) Convert register access to regmap API") I reused the 'reg' variable for all three register reads in the fan speed calculation loop in nct6775_update_device(), but failed to notice that the value from the first one (data->REG_FAN[i]) is actually used in the call to nct6775_select_fan_div() at the end of the loop body. Since that patch the register value passed to nct6775_select_fan_div() has been (conditionally) incorrectly clobbered with the value of a different register than intended, which has in at least some cases resulted in fan speeds being adjusted down to zero. Fix this by using dedicated temporaries for the two intermediate register reads instead of 'reg'. Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Fixes: 4ef27745 ("hwmon: (nct6775) Convert register access to regmap API") Reported-by:
Thomas Zajic <zlatko@gmx.at> Tested-by:
-
Zhang Rui authored
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: 7108b80a ("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.comSigned-off-by:
-
