- 18 Mar, 2019 8 commits
-
-
Axel Lin authored
Make it consistent as .volt_table should be const unsigned int *. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Axel Lin authored
Make it consistent as .volt_table should be const unsigned int *. Signed-off-by:
-
Axel Lin authored
Make it consistent as .volt_table should be const unsigned int *. Signed-off-by:
-
Axel Lin authored
This driver does not really need struct as3711_regulator_info and struct as3711_regulator, remove them. Signed-off-by:
-
Axel Lin authored
Use of_device_get_match_data to simplify the code a bit. Signed-off-by:
-
Axel Lin authored
This driver is using regulator core's simplified DT parsing code, so regulator will call regulator_of_get_init_data() to get init_data. No need to set config.init_data. In additional, current code does not properly set the init_data setting, so just remove it. Signed-off-by:
-
Axel Lin authored
Current code is using devm_regulator_register() so it is not necessary to save as3722_regs->rdevs[id] for clean up. The *rdevs[] is not used now, remove it. Signed-off-by:
-
Axel Lin authored
Remove #ifdef CONFIG_OF guard so linux/of.h will be included when !CONFIG_OF. This fixes build warnings when !CONFIG_OF. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by:
-
- 15 Mar, 2019 3 commits
-
-
Axel Lin authored
Use regulator core's simplified DT parsing code to simply the driver implementation. Signed-off-by:
-
Axel Lin authored
Use regulator core's simplified DT parsing code to simply the driver implementation. Signed-off-by:
-
Axel Lin authored
The struct pm800_regulators only has 2 members: *chip and *map. The pm800_data->chip is not used. The pm800_data->map is not necessary. Thus remove the struct pm800_regulators. Signed-off-by:
-
- 13 Mar, 2019 21 commits
-
-
Axel Lin authored
Use regulator_set/get_current_limit_regmap helpers to save some code. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
-
Axel Lin authored
Use regulator_set/get_current_limit_regmap helpers to save some code. Signed-off-by:
-
Axel Lin authored
.set_current_limit callback should select the current closest to max_uA. Signed-off-by:
-
Axel Lin authored
.set_current_limit callback should select the current closest to max_uA. Signed-off-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d1c6b4fe ("regulator: Add WM831x LDO support") Suggested-by:
Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: d4d6b722 ("regulator: Add WM831x ISINK support") Suggested-by:
-
Axel Lin authored
This driver has been converted to use regulator core's simplified DT parsing code. So the match_init_data/match_of_node functions are not necessary now, remove them. Signed-off-by:
-
Arnd Bergmann authored
The da903x driver produces an annoying false-positive warning when built with clang: drivers/regulator/da903x.c:395:2: error: division by zero is undefined [-Werror,-Wdivision-by-zero] DA9030_LDO(13, 2100, 2100, 0, INVAL, 0, 0, RCTL11, 3), /* fixed @2.1V */ ^ ~ drivers/regulator/da903x.c:359:2: note: expanded from macro 'DA9030_LDO' DA903x_LDO(DA9030, _id, min, max, step, vreg, shift, nbits, ereg, ebit) ^ ~~~~ drivers/regulator/da903x.c:320:39: note: expanded from macro 'DA903x_LDO' .n_voltages = (step) ? ((max - min) / step + 1) : 1, \ ^ ~~~~ drivers/regulator/da903x.c:415:2: error: division by zero is undefined [-Werror,-Wdivision-by-zero] DA9034_LDO(5, 3100, 3100, 0, INVAL, 0, 0, OVER3, 7), /* fixed @3.1V */ ^ ~ drivers/regulator/da903x.c:356:2: note: expanded from macro 'DA9034_LDO' DA903x_LDO(DA9034, _id, min, max, step, vreg, shift, nbits, ereg, ebit) ^ ~~~~ drivers/regulator/da903x.c:320:39: note: expanded from macro 'DA903x_LDO' .n_voltages = (step) ? ((max - min) / step + 1) : 1, \ ^ ~~~~ I already reported this as a bug in clang, but it may take a while to fix it. As I have not been able to come up with any reasonable workaround, I would just disable compilation here. Link: https://bugs.llvm.org/show_bug.cgi?id=38789Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f307a7e9 ("regulator: pv88060: new regulator driver") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 37b918a0 ("regulator: Add LTC3676 support") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 3eb2c7ec ("regulator: Add LTC3589 support") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: b59320cc ("regulator: lp8755: new driver for LP8755") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 1028a37d ("regulator: da9211: new regulator driver") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 69ca3e58 ("regulator: da9063: Add Dialog DA9063 voltage regulators support.") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: e4ee831f ("regulator: Add WM831x DC-DC buck convertor support") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: c90456e3 ("regulator: pv88090: new regulator driver") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 99cf3af5 ("regulator: pv88080: new regulator driver") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: 4068e518 ("regulator: da9062: DA9062 regulator driver") Suggested-by:
-
Steve Twiss authored
The mutex for the regulator_dev must be controlled by the caller of the regulator_notifier_call_chain(), as described in the comment for that function. Failure to mutex lock and unlock surrounding the notifier call results in a kernel WARN_ON_ONCE() which will dump a backtrace for the regulator_notifier_call_chain() when that function call is first made. The mutex can be controlled using the regulator_lock/unlock() API. Fixes: f6130be6 ("regulator: DA9055 regulator driver") Suggested-by:
-
Axel Lin authored
gpio_regulator_voltage_ops and gpio_regulator_current_ops should never change, make them const. Signed-off-by:
-
Axel Lin authored
Use devm_regulator_register to simplify the code. Signed-off-by:
-
- 11 Mar, 2019 4 commits
-
-
Axel Lin authored
Use WM8400_DC2_ENA_MASK for DCDC2 enable_mask. The define is the same as WM8400_DC1_ENA_MASK, just a cleanup. Signed-off-by:
-
Axel Lin authored
The only user of wm8400_block_read/wm8400_set_bits functions is the wm8400 regulator driver. At the context of all the callers, we can use regmap_bulk_read/regmap_update_bits directly. Thus remove wm8400_block_read/wm8400_set_bits functions. Signed-off-by:
-
Axel Lin authored
Current code is using devm_regulator_register() so it is not necessary to save reg->rdev for clean up. Remove *rdev from struct ab3100_regulator, then ab3100_regulators_remove() can be removed as well. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Axel Lin authored
This driver is using devm_regulator_register() so it is not necessary to save *rdev for clean up. Actually the pmic->rdev[id] is not used now. Signed-off-by:
-
- 04 Mar, 2019 4 commits
-
-
Mark Brown authored
-
Mark Brown authored
-
Axel Lin authored
These regulator_ops variables should never change, make them const. Signed-off-by:
-
Axel Lin authored
The palmas_smps_ramp_delay array should never modify, make it const. Signed-off-by:
-
