- 28 Oct, 2023 17 commits
-
-
Antoniu Miclaus authored
Add missing implementation for the max31827 supply regulator. This is a hardware required property that is not handled. Signed-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20230925122929.10610-1-antoniu.miclaus@analog.comSigned-off-by:
Guenter Roeck <linux@roeck-us.net>
-
Ninad Malwade authored
The INA3221 allows the Critical alert pin to be controlled by the summation control function. This function adds the single shunt-voltage conversions for the desired channels in order to compare the combined sum to the programmed limit. The Shunt-Voltage Sum Limit register contains the programmed value that is compared to the value in the Shunt-Voltage Sum register in order to determine if the total summed limit is exceeded. If the shunt-voltage sum limit value is exceeded, the Critical alert pin pulls low. For the summation limit to have a meaningful value, we have to use the same shunt-resistor value on all included channels. Unless equal shunt-resistor values are used for each channel, the summation control function cannot be used and it is not enabled by the driver. To address this, add support to disable the summation of specific channels via device tree property "ti,summation-disable". The channel which has this property would be excluded from the calculation of summation control function. For example, summation control function calculates Shunt-Voltage Sum as: - input_shunt_voltage_summation = input_shunt_voltage_channel1 + input_shunt_voltage_channel2 + input_shunt_voltage_channel3 If we want the summation to only use channel1 and channel3, we can add 'ti,summation-disable' property in device tree node for channel2. Then the calculation will skip channel2. - input_shunt_voltage_summation = input_shunt_voltage_channel1 + input_shunt_voltage_channel3 Note that we only want the channel to be skipped for summation control function rather than completely disabled. Therefore, even if we add the property 'ti,summation-disable', the channel is still enabled and functional. Finally, create debugfs entries that display if summation is disabled for each of the channels. Signed-off-by:Rajkumar Kasirajan <rkasirajan@nvidia.com> Signed-off-by:
Ninad Malwade <nmalwade@nvidia.com> Co-developed-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Jon Hunter authored
The INA3221 has a critical alert pin that can be controlled by the summation control function. This function adds the single shunt-voltage conversions for the desired channels in order to compare the combined sum to the programmed limit. The Shunt-Voltage Sum Limit register contains the programmed value that is compared to the value in the Shunt-Voltage Sum register in order to determine if the total summed limit is exceeded. If the shunt-voltage sum limit value is exceeded, the critical alert pin pulls low. For the summation limit to have a meaningful value, it is necessary to use the same shunt-resistor value on all included channels. Add a new vendor specific property, 'ti,summation-disable', to allow specific channels to be excluded from the summation control function if the shunt resistor is different to other channels or the channel should not be considered for triggering the critical alert pin. Note that the ina3221 has always supported summing the various input channels and summation is enabled by default if the shunt-resistor values are the same. This change simply provides a way to exclude inputs from the summation. If this property is not populated, then the functionality of the driver does not change. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230929103650.86074-3-jonathanh@nvidia.comSigned-off-by:
-
Ninad Malwade authored
Convert the TI INA3221 bindings from the free-form text format to json-schema. Note that the INA3221 input channels default to enabled in the chip. Unless channels are explicitly disabled in device-tree, input channels will be enabled. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Saravanan Sekar authored
The MPQ2286 is a programmable, high frequency synchronous buck regulator designed to power a variety of Automotive system peripherals. Single buck converters with hardware monitoring capability is configurable over PMBus interface. Signed-off-by:
Saravanan Sekar <saravanan@linumiz.com> Link: https://lore.kernel.org/r/20231011164754.449399-5-saravanan@linumiz.com [groeck: Updated subject (mpq2286 -> mpq7932)] Signed-off-by:
-
Saravanan Sekar authored
The bindings for single instance regulator should be named with no instance (e.g., buck not buck0). Introduce a new helper macro to define the single pmbus regulator. Signed-off-by:
-
Saravanan Sekar authored
Document mpq2286 power-management IC. Signed-off-by:
Mark Brown <broonie@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231011164754.449399-3-saravanan@linumiz.comSigned-off-by:
-
Saravanan Sekar authored
Get page count using compatible match to support the series of chipsets which differs in number of regualator/page. Signed-off-by:
-
Daniel Matyas authored
These modify the corresponding bits in the configuration register. adi,comp-int is a hardware property, because it affects the behavior of the interrupt signal and whatever it is connected to. adi,timeout-enable is a hardware property, because it affects i2c bus operation. Signed-off-by:
Daniel Matyas <daniel.matyas@analog.com> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230919093456.10592-3-daniel.matyas@analog.comSigned-off-by:
-
Daniel Matyas authored
There is nothing in the datasheet indicating that the 1ms error is needed and I didn't encounter any error during testing with 140ms wait time. Signed-off-by:
-
Daniel Matyas authored
Used enums and while loops to replace switch for selecting and getting update interval from conversion rate bits. Divided the write_alarm_val function into 2 functions. The new function is more generic: it can be used not only for alarm writes, but for any kind of writes which require the device to be in shutdown mode. Signed-off-by:
-
Hal Feng authored
As he is the submitter of this driver, add his mail so he can maintain the driver and easily reply in the mailing list. Acked-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
Hal Feng <hal.feng@starfivetech.com> Link: https://lore.kernel.org/r/20230928075249.109459-1-hal.feng@starfivetech.comSigned-off-by:
-
Alexander Koskovich authored
This value was found on an ASRock X670E Taichi with an NCT6686D chip. Signed-off-by:
Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20231023182442.21943-1-akoskovich@pm.meSigned-off-by:
-
Antoniu Miclaus authored
Do not allow setting shunt resistor to 0. This results in a division by zero when performing current value computations based on input voltages and connected resistor values. Signed-off-by:
-
Su Hui authored
npcm7xx_pwm_config_set() can return '-ENODEV' for failed. So check the value of 'ret' after calling npcm7xx_pwm_config_set(). Signed-off-by:
Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231020085518.198477-1-suhui@nfschina.comSigned-off-by:
-
Colin Ian King authored
Currently the local variable hum is being divided by a constant and the results is being re-assigned back to hum before the value is being returned to the caller. The assignment to hum is redundant and can be removed. Cleans up clang scan build warning: drivers/hwmon/hs3001.c:65:9: warning: Although the value stored to 'hum' is used in the enclosing expression, the value is never actually read from 'hum' [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20231023135828.667297-1-colin.i.king@gmail.comSigned-off-by:
-
Raag Jadav authored
Convert manual _UID references to use the standard ACPI helper. Signed-off-by:
Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20231024062018.23839-6-raag.jadav@intel.comSigned-off-by:
-
- 27 Oct, 2023 23 commits
-
-
Timothy Pearson authored
Add support for the ADT7490's Imon voltage readout. It is handled largely the same way as the existing Vtt readout. Signed-off-by:
Timothy Pearson <tpearson@raptorengineering.com> Co-developed-by:
Shawn Anastasio <sanastasio@raptorengineering.com> Signed-off-by:
-
Thomas Weißschuh authored
The KM002C is similar to the KM003C and seems to use the same protocol and firmware. Reported-by:
Douglas Gilbert <dgilbert@interlog.com> Closes: https://lore.kernel.org/lkml/290ebce4-54f0-8ac1-2a13-cbc806d80d64@interlog.com/Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230911-powerz-km002c-v1-1-898bd79b9bae@weissschuh.netSigned-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 <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230918085951.1234172-25-u.kleine-koenig@pengutronix.deSigned-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:
-
