aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2020-01-03regulator: bd70528: Remove .set_ramp_delay for bd70528_ldo_opsAxel Lin1-1/+0
The .set_ramp_delay should be for bd70528_buck_ops only. Setting .set_ramp_delay for for bd70528_ldo_ops causes problem because BD70528_MASK_BUCK_RAMP (0x10) overlaps with BD70528_MASK_LDO_VOLT (0x1f). So setting ramp_delay for LDOs may change the voltage output, fix it. Fixes: 99ea37bd1e7d ("regulator: bd70528: Support ROHM BD70528 regulator block") Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200101022406.15176-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-25regulator: axp20x: Fix axp20x_set_ramp_delayAxel Lin1-3/+6
Current code set incorrect bits when set ramp_delay for AXP20X_DCDC2, fix it. Fixes: d29f54df8b16 ("regulator: axp20x: add support for set_ramp_delay for AXP209") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191221081049.32490-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-18regulator: axp20x: Fix AXP22x ELDO2 regulator enable bitmaskChen-Yu Tsai1-1/+1
A copy-paste error was introduced when bitmasks were converted to macros, incorrectly setting the enable bitmask for ELDO2 to the one for ELDO1 for the AXP22x units. Fix it by using the correct macro. On affected boards, ELDO1 and/or ELDO2 are used to power the camera, which is currently unsupported. Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20191218044720.21990-1-wens@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-16regulator: rn5t618: fix module aliasesAndreas Kemnade1-0/+1
platform device aliases were missing, preventing autoloading of module. Fixes: 811b700630ff ("regulator: rn5t618: add driver for Ricoh RN5T618 regulators") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://lore.kernel.org/r/20191211221600.29438-1-andreas@kemnade.info Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-11regulator: max77650: add of_match tableBartosz Golaszewski1-0/+7
We need the of_match table if we want to use the compatible string in the pmic's child node and get the regulator driver loaded automatically. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20191210100725.11005-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-09regulator: core: avoid unneeded .list_voltage callsCristian Marussi1-0/+4
Inside machine_constraints_voltage() a loop is in charge of verifying that each of the defined voltages are within the configured constraints and that those constraints are in fact compatible with the available voltages' list. When the registered regulator happens to be defined with a wide range of possible voltages the above O(n) loop can be costly. Moreover since this behaviour is triggered during the registration process, it means also that it can be easily triggered at probe time, slowing down considerably some module loading. On the other side if such wide range of voltage values happens to be also continuous and without discontinuity of any kind, the above potentially cumbersome operation is also useless. For these reasons, avoid such .list_voltage poll loop when regulator is described as 'continuous_voltage_range' as is, indeed, similarly already done inside regulator_is_supported_voltage(). Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20191209125239.46054-1-cristian.marussi@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-04regulator: s5m8767: Fix a warning messageChristophe JAILLET1-1/+1
Axe a duplicated word ("property") in a warning message. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20191203214838.9680-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-03regulator: core: fix regulator_register() error paths to properly release rdevWen Yang1-2/+6
There are several issues with the error handling code of the regulator_register() function: ret = device_register(&rdev->dev); if (ret != 0) { put_device(&rdev->dev); --> rdev released goto unset_supplies; } ... unset_supplies: ... unset_regulator_supplies(rdev); --> use-after-free ... clean: if (dangling_of_gpiod) gpiod_put(config->ena_gpiod); kfree(rdev); --> double free We add a variable to record the failure of device_register() and move put_device() down a bit to avoid the above issues. Fixes: c438b9d01736 ("regulator: core: Move registration of regulator device") Signed-off-by: Wen Yang <wenyang@linux.alibaba.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27regulator: fix use after free issueWen Yang1-2/+2
This is caused by dereferencing 'rdev' after put_device() in the _regulator_get()/_regulator_put() functions. This patch just moves the put_device() down a bit to avoid the issue. Signed-off-by: Wen Yang <wenyang@linux.alibaba.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-22regulator: da9062: Return REGULATOR_MODE_INVALID for invalid modeAxel Lin1-1/+1
-EINVAL is not a valid return value for .of_map_mode, return REGULATOR_MODE_INVALID instead. Fixes: 844e7492ee3d ("regulator: da9062: add of_map_mode support for bucks") Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191122045154.802-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20regulator: Fix Kconfig indentationKrzysztof Kozlowski1-4/+4
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20191120133949.13996-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20regulator: tps6105x: add optional devicetree supportSven Van Asbroeck1-0/+2
Tell the regulator framework to retrieve regulator init data from the 'regulator' subnode, or from the parent mfd device's platform data. Example: i2c0 { tps61052@33 { compatible = "ti,tps61052"; reg = <0x33>; regulator { regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; regulator-always-on; }; }; }; Tree: next-20191118 Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Link: https://lore.kernel.org/r/20191119154611.29625-3-TheSven73@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-20tps6105x: add optional devicetree supportSven Van Asbroeck1-3/+31
This driver currently requires platform data to specify the operational mode and regulator init data (in case of regulator mode). Optionally specify the operational mode by looking at the name of the devicetree child node. Example: put chip in regulator mode: i2c0 { tps61052@33 { compatible = "ti,tps61052"; reg = <0x33>; regulator { regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; regulator-always-on; }; }; }; Tree: linux-next Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Link: https://lore.kernel.org/r/20191119154611.29625-2-TheSven73@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-18regulator: vexpress: Use PTR_ERR_OR_ZERO() to simplify codezhengbin1-4/+1
Fixes coccicheck warning: drivers/regulator/vexpress-regulator.c:78:1-3: WARNING: PTR_ERR_OR_ZERO can be used Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Link: https://lore.kernel.org/r/1574074762-34629-1-git-send-email-zhengbin13@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-15dt-bindings: mfd: da9062: describe buck modesChristoph Fritz1-0/+4
This patch adds DT description of da9062 buck regulator modes. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Link: https://lore.kernel.org/r/1573652416-9848-4-git-send-email-chf.fritz@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-15regulator: da9062: add of_map_mode support for bucksChristoph Fritz1-0/+21
This patch adds of_map_mode support for bucks to set regulator modes from within regulator framework. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by: Christian Hemp <c.hemp@phytec.de> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Link: https://lore.kernel.org/r/1573652416-9848-3-git-send-email-chf.fritz@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-15regulator: da9062: refactor buck modes into headerChristoph Fritz2-18/+26
This patch refactors buck modes into a header file so that device trees can make use of these mode constants. The new header filename uses da9063 because DA9063 was the earlier chip and its driver code will want updating at some point in a similar manner. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Link: https://lore.kernel.org/r/1573652416-9848-2-git-send-email-chf.fritz@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-15regulator: stpmic1: Set a default ramp delay valuePascal Paillet1-0/+6
Set a default ramp delay value to the regulators with the worst case value. Signed-off-by: pascal paillet <p.paillet@st.com> Link: https://lore.kernel.org/r/20191113161529.27739-1-p.paillet@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-15regulator: core: Let boot-on regulators be powered offPascal Paillet1-1/+3
Boot-on regulators are always kept on because their use_count value is now incremented at boot time and never cleaned. Only increment count value for alway-on regulators. regulator_late_cleanup() is now able to power off boot-on regulators when unused. Fixes: 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies") Signed-off-by: Pascal Paillet <p.paillet@st.com> Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-07regulator: ab8500: Remove SYSCLKREQ from enum ab8505_regulator_idStephan Gerhold1-2/+0
Those regulators are not actually supported by the AB8500 regulator driver. There is no ab8500_regulator_info for them and no entry in ab8505_regulator_match. As such, they cannot be registered successfully, and looking them up in ab8505_regulator_match causes an out-of-bounds array read. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191106173125.14496-2-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-07regulator: ab8500: Remove AB8505 USB regulatorStephan Gerhold2-18/+0
The USB regulator was removed for AB8500 in commit 41a06aa738ad ("regulator: ab8500: Remove USB regulator"). It was then added for AB8505 in commit 547f384f33db ("regulator: ab8500: add support for ab8505"). However, there was never an entry added for it in ab8505_regulator_match. This causes all regulators after it to be initialized with the wrong device tree data, eventually leading to an out-of-bounds array read. Given that it is not used anywhere in the kernel, it seems likely that similar arguments against supporting it exist for AB8505 (it is controlled by hardware). Therefore, simply remove it like for AB8500 instead of adding an entry in ab8505_regulator_match. Fixes: 547f384f33db ("regulator: ab8500: add support for ab8505") Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191106173125.14496-1-stephan@gerhold.net Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-06regulator: fan53555: add chip id for Silergy SYR83XVasily Khoruzhick1-0/+2
SYR83X is used in Rockpro64 and it has die ID == 9. All other registers are the same as in SYR82X Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://lore.kernel.org/r/20191106161211.1700663-1-anarsoul@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-29regulator: fixed: add off-on-delayPeng Fan2-0/+3
Depends on board design, the gpio controlling regulator may connects with a big capacitance. When need off, it takes some time to let the regulator to be truly off. If not add enough delay, the regulator might have always been on, so introduce off-on-delay to handle such case. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1572311875-22880-3-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-29dt-bindings: regulator: fixed: add off-on-delay-us propertyPeng Fan1-0/+4
When disabling a fixed regulator, it may take some time to let the voltage drop to the expected value, such as zero. If not delay enough time, the regulator might have been always enabled. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1572311875-22880-2-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-28regulator: core: Allow generic coupling only for always-on regulatorsDmitry Osipenko1-0/+6
The generic voltage balancer doesn't work correctly if one of regulator couples turns off. Currently there are no users in kernel for that case, although let's explicitly show that this case is unsupported for those who will try to use that feature. Link: https://lore.kernel.org/linux-samsung-soc/20191008170503.yd6GscYPLxjgrXqDuCO7AJc6i6egNZGJkVWHLlCxvA4@z/ Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20191025002240.25288-2-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09regulator: uniphier: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191009150203.8052-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-09regulator: stm32-vrefbuf: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20191009150138.11640-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: da9062: Simplify da9062_buck_set_mode for BUCK_MODE_MANUAL caseAxel Lin1-6/+3
The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify the logic as the result is the same. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20191007115009.25672-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: rk808: Remove rk817_set_suspend_voltage functionAxel Lin1-16/+1
The implement is exactly the same as rk808_set_suspend_voltage, so just use rk808_set_suspend_voltage instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191008010628.8513-3-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: rk808: Fix warning message in rk817_set_ramp_delayAxel Lin1-1/+1
The default in rk817_set_ramp_delay is 25MV rather than 10MV. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191008010628.8513-2-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-08regulator: rk808: Constify rk817 regulator_opsAxel Lin1-5/+5
These regulator_ops variables never need to be modified, make them const so compiler can put them to .rodata. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191008010628.8513-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: max77686: switch to using fwnode_gpiod_get_indexDmitry Torokhov1-2/+3
gpiod_get_from_of_node() is being retired in favor of fwnode_gpiod_get_index(), that behaves similar to gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-8-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: tps65132: switch to using devm_fwnode_gpiod_get()Dmitry Torokhov1-7/+10
devm_fwnode_get_index_gpiod_from_child() is going away as the name is too unwieldy, let's switch to using the new devm_fwnode_gpiod_get(). Note that we no longer need to check for NULL as devm_fwnode_gpiod_get() will return -ENOENT if GPIO is missing. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-7-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: da9211: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-6/+6
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20191004231017.130290-6-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: s2mps11: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-4/+3
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-5-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: tps65090: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-11/+15
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-4-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: slg51000: switch to using fwnode_gpiod_get_indexDmitry Torokhov1-8/+5
devm_gpiod_get_from_of_node() is being retired in favor of [devm_]fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Note that now that we have a good non-devm API for getting GPIO from arbitrary firmware node, there is no reason to use devm API here as regulator core takes care of managing lifetime of "enable" GPIO and we were immediately detaching requested GPIO from devm anyway. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-3-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: s5m8767: switch to using devm_fwnode_gpiod_getDmitry Torokhov1-4/+3
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20191004231017.130290-2-dmitry.torokhov@gmail.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: pbias: Get rid of struct pbias_regulator_dataAxel Lin1-43/+26
Only the desc field is really used, so use struct regulator_desc instead. Then struct pbias_regulator_data can be removed. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20191007114320.20977-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-07regulator: da9062: Simplify the code iterating all regulatorsAxel Lin1-4/+1
It's more straightforward to use for statement here. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Steve Twiss <stwiss.opensource@diasemi.com> Link: https://lore.kernel.org/r/20191007115009.25672-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: qcom-rpmh: add PM6150/PM6150L regulator supportKiran Gunda1-1/+61
Add support for PM6150/PM6150L regulators. This ensures that consumers are able to modify the physical state of PMIC regulators. Signed-off-by: Kiran Gunda <kgunda@codeaurora.org> Link: https://lore.kernel.org/r/1570183734-30706-3-git-send-email-kgunda@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: dt-bindings: Add PM6150x compatiblesKiran Gunda1-0/+4
Add PM6150 and PM6150L compatibles for Qualcomm SC7180 platfrom. Signed-off-by: Kiran Gunda <kgunda@codeaurora.org> Link: https://lore.kernel.org/r/1570183734-30706-2-git-send-email-kgunda@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: max8907: Fix the usage of uninitialized variable in max8907_regulator_probe()Yizhuo1-3/+12
Inside function max8907_regulator_probe(), variable val could be uninitialized if regmap_read() fails. However, val is used later in the if statement to decide the content written to "pmic", which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-04regulator: qcom-rpmh: Fix PMIC5 BoB min voltageKiran Gunda1-2/+2
Correct the PMIC5 BoB min voltage from 0.3V to 3V. Also correct the voltage selector accordingly. Signed-off-by: Kiran Gunda <kgunda@codeaurora.org> Link: https://lore.kernel.org/r/1570184215-5355-1-git-send-email-kgunda@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-03gpiolib: introduce fwnode_gpiod_get_index()Dmitry Torokhov3-15/+62
This introduces fwnode_gpiod_get_index() that iterates through common gpio suffixes when trying to locate a GPIO within a given firmware node. We also switch devm_fwnode_gpiod_get_index() to call fwnode_gpiod_get_index() instead of iterating through GPIO suffixes on its own. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190913032240.50333-3-dmitry.torokhov@gmail.com Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-10-03gpiolib: introduce devm_fwnode_gpiod_get_index()Dmitry Torokhov2-20/+40
devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode in question does not have to be a child of device node. Let's rename it to devm_fwnode_gpiod_get_index() and keep the old name for compatibility for now. Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the callers need a single GPIO. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20190913032240.50333-2-dmitry.torokhov@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-10-02regulator: Document "regulator-boot-on" binding more thoroughlyDouglas Anderson1-1/+6
The description of "regulator-boot-on" was a little unclear, at least to me. Did this property mean that we should turn the regulator on at boot? Or perhaps it was intended only to be used for regulators where we couldn't read the state at bootup to indicate what state we should assume? The answer, it turns out, is both [1]. Let's document this. [1] https://lore.kernel.org/r/20190923181431.GU2036@sirena.org.uk Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20191001124531.v2.1.Ice34ad5970a375c3c03cb15c3859b3ee501561bf@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: bd718x7: Add MODULE_ALIAS()Guido Günther1-0/+1
This fixes device probing when built as a module Signed-off-by: Guido Günther <agx@sigxcpu.org> Link: https://lore.kernel.org/r/46ce3400e227dd88d51486c02a6152c9ec52acbb.1569875042.git.agx@sigxcpu.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: pfuze100-regulator: Variable "val" in pfuze100_regulator_probe() could be uninitializedYizhuo1-1/+7
In function pfuze100_regulator_probe(), variable "val" could be initialized if regmap_read() fails. However, "val" is used to decide the control flow later in the if statement, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20190929170957.14775-1-yzhai003@ucr.edu Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01regulator: lochnagar: Add on_off_delay for VDDCORECharles Keepax1-0/+1
The VDDCORE regulator takes a good length of time to discharge down, so add an on_off_delay to ensure DCVDD is removed before it is powered on again. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20191001132017.1785-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.