- 01 Oct, 2019 2 commits
-
-
Charles Keepax authored
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.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Axel Lin authored
ti_abb_wait_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns true in the latest iteration of the while loop because the timeout value is abb->settling_time + 1. Similarly, ti_abb_clear_all_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns false in the latest iteration of the while loop. Fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20190929095848.21960-1-axel.lin@ingics.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 23 Sep, 2019 3 commits
-
-
Marco Felsch authored
Currently the suspend reg_field maps to the pmic voltage selection bits and is used during suspend_enabe/disable() and during get_mode(). This seems to be wrong for both use cases. Use case one (suspend_enabe/disable): Those callbacks are used to mark a regulator device as enabled/disabled during suspend. Marking the regulator enabled during suspend is done by the LDOx_CONF/BUCKx_CONF bit within the LDOx_CONT/BUCKx_CONT registers. Setting this bit tells the DA9062 PMIC state machine to keep the regulator on in POWERDOWN mode and switch to suspend voltage. Use case two (get_mode): The get_mode callback is used to retrieve the active mode state. Since the regulator-setting-A is used for the active state and regulator-setting-B for the suspend state there is no need to check which regulator setting is active. Fixes: 4068e518 ("regulator: da9062: DA9062 regulator driver") Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20190917124246.11732-2-m.felsch@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>
-
Philippe Schenker authored
Remove 'const:' in the compatible enum. This was breaking make dt_binding_check since it has more than one compatible string. Fixes: 9c86d003 ("dt-bindings: regulator: add regulator-fixed-clock binding") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20190923081840.23391-1-philippe.schenker@toradex.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Axel Lin authored
Use of_device_get_match_data which has NULL test for match before dereference match->data. Add NULL test for drvtype so it still works for fixed_voltage_ops when !CONFIG_OF. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20190922022928.28355-1-axel.lin@ingics.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 17 Sep, 2019 2 commits
-
-
Marco Felsch authored
Sometimes it can happen that the regulator_of_get_init_data() can't retrieve the config due to a not probed device the regulator depends on. Fix that by checking the return value of of_parse_cb() and return EPROBE_DEFER in such cases. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20190917154021.14693-4-m.felsch@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>
-
Marco Felsch authored
Currently the regulator-suspend-min/max-microvolt must be within the root regulator node but the dt-bindings specifies it as subnode properties for the regulator-state-[mem/disk/standby] node. The only DT using this bindings currently is the at91-sama5d2_xplained.dts and this DT uses it correctly. I don't know if it isn't tested but it can't work without this fix. Fixes: f7efad10 ("regulator: add PM suspend and resume hooks") Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20190917154021.14693-3-m.felsch@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 11 Sep, 2019 3 commits
-
-
H. Nikolaus Schaller authored
regulator_uV_show() is missing error handling if regulator_get_voltage_rdev() returns negative values. Instead it prints the errno as a string, e.g. -EINVAL as "-22" which could be interpreted as -22 µV. We also do not need to hold the lock while converting the integer to a string. Reported-by: Adam Ford <aford173@gmail.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Tested-by: Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/f37f2a1276efcb34cf3b7f1a25481175be048806.1568143348.git.hns@goldelico.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Torokhov authored
This fixes 11da04af, as devm_gpiod_get_from_of_node() does not do translation "con-id" -> "con-id-gpios" that our bindings expects, and therefore it was wrong to change connection ID to be simply "enable" when moving to using devm_gpiod_get_from_of_node(). Fixes: 11da04af ("regulator: da9211: Pass descriptors instead of GPIO numbers") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190910170246.GA56792@dtor-wsSigned-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Torokhov authored
This fixes 96392c3d, as devm_gpiod_get_from_of_node() does not do translation "con-id" -> "con-id-gpios" that our bindings expects, and therefore it was wrong to change connection ID to be simply "maxim,ena" when moving to using devm_gpiod_get_from_of_node(). Fixes: 96392c3d ("regulator: max77686: Pass descriptor instead of GPIO number") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190910170050.GA55530@dtor-wsSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 10 Sep, 2019 4 commits
-
-
Kunihiko Hayashi authored
Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is equivalent to Pro4. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1568080304-1572-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Philippe Schenker authored
This adds the documentation to the compatible regulator-fixed-clock. This binding is a special binding of regulator-fixed and adds the ability to add a clock to regulator-fixed, so the regulator can be enabled and disabled with that clock. If the special compatible regulator-fixed-clock is used it is mandatory to supply a clock. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20190910062103.39641-4-philippe.schenker@toradex.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Philippe Schenker authored
This commit adds the possibility to choose the compatible "regulator-fixed-clock" in devicetree. This is a special regulator-fixed that has to have a clock, from which the regulator gets switched on and off. Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Link: https://lore.kernel.org/r/20190910062103.39641-2-philippe.schenker@toradex.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Krzysztof Kozlowski authored
The value under 's2mps11->ext_control_gpiod[i]' is assigned to local variable and used in probe in one place before. Use it consistently later so code will be easier to read. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20190909155723.24734-1-krzk@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 09 Sep, 2019 4 commits
-
-
Axel Lin authored
Use rdev->regmap/&rdev->dev instead of lp87565->regmap/lp87565->dev. In additional, the lp87565->dev actually is the parent mfd device, so the dev_err message is misleading here with lp87565->dev. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20190908035720.17748-1-axel.lin@ingics.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Dmitry Torokhov authored
The CS GPIO line is clearly optional GPIO (and marked as such in the binding document) and we should handle it accordingly. The current code treats all errors as meaning that there is no GPIO defined, which is wrong, as it does not handle deferrals raised by the underlying code properly, nor does it recognize non-existing GPIO from any other initialization error. As far as I can see the only reason the driver, unlike all others, is using OF-specific devm_gpiod_get_from_of_node() so that it can assign a custom label to the selected GPIO line. Given that noone else needs that, it should not be doing that either. Let's switch to using more appropriate devm_gpiod_get_optional(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190904214200.GA66118@dtor-wsSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
-
Colin Ian King authored
Don't populate the array en_mask on the stack but instead make it static const. Makes the object code smaller by 87 bytes. Before: text data bss dec hex filename 12967 3408 0 16375 3ff7 drivers/regulator/lp8788-ldo.o After: text data bss dec hex filename 12816 3472 0 16288 3fa0 drivers/regulator/lp8788-ldo.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190906130632.6709-1-colin.king@canonical.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 05 Sep, 2019 1 commit
-
-
Guido Günther authored
In case of a missing (optional) gpio don't fall through up to "ti,active-discharge-time-us" due to devm_fwnode_get_index_gpiod_from_child() returning NULL (since gpiod_get_from_of_node() returned NULL) but rather indicate success as intended. This makes the driver probe correctly when e.g. only the enable gpio is given. Signed-off-by: Guido Günther <agx@sigxcpu.org> Link: https://lore.kernel.org/r/363bd50cc7c60daa57d614a341d1fd649f05194c.1567625660.git.agx@sigxcpu.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 04 Sep, 2019 1 commit
-
-
Mark Brown authored
The kernel has no way of knowing when we have finished instantiating drivers, between deferred probe and systems that build key drivers as modules we might be doing this long after userspace has booted. This has always been a bit of an issue with regulator_init_complete since it can power off hardware that's not had it's driver loaded which can result in user visible effects, the main case is powering off displays. Practically speaking it's not been an issue in real systems since most systems that use the regulator API are embedded and build in key drivers anyway but with Arm laptops coming on the market it's becoming more of an issue so let's do something about it. In the absence of any better idea just defer the powering off for 30s after late_initcall(), this is obviously a hack but it should mask the issue for now and it's no more arbitrary than late_initcall() itself. Ideally we'd have some heuristics to detect if we're on an affected system and tune or skip the delay appropriately, and there may be some need for a command line option to be added. Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org> Tested-by: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org
-
- 03 Sep, 2019 1 commit
-
-
Bartosz Golaszewski authored
The build fails when CONFIG_REGULATOR is not selected because the stub for regulator_bulk_set_supply_names() is missing the 'static inline' attribute. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190902151332.28058-1-brgl@bgdev.plSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 02 Sep, 2019 1 commit
-
-
Bartosz Golaszewski authored
There are many regulator consumers who - before using the regulator bulk functions - set the supply names in regulator_bulk_data using a for loop. Let's provide a simple helper in the consumer API that allows users to do the same with a single function call. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190830071740.4267-2-brgl@bgdev.plSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 30 Aug, 2019 4 commits
-
-
Mark Brown authored
In an effort to try to contain abuses of regulator_get_optional() add a keyword entry to the MAINTAINERS stanza for the regulator API so that the regulator maintainers get CCed on new usages. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20190829125435.48770-1-broonie@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
Add prefixes to BUCK_EN and MODE macros to namespace them. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190829143927.395d0385@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
Update the entire comment block to be C++ style so it looks consistent. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190829143749.4b42bc65@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
The mt6358 driver was merged in error, it depends on an existing MFD rather than a newly added one and needs updates to that driver. Disable the build until those are merged. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mark Brown <broonie@kernel.org>
-
- 28 Aug, 2019 2 commits
-
-
Hsin-Hsiung Wang authored
The MT6358 is a regulator found on boards based on MediaTek MT8183 and probably other SoCs. It is a so called pmic and connects as a slave to SoC using SPI, wrapped inside the pmic-wrapper. Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Link: https://lore.kernel.org/r/1566531931-9772-8-git-send-email-hsin-hsiung.wang@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Hsin-Hsiung Wang authored
add dt-binding document for MediaTek MT6358 PMIC Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Link: https://lore.kernel.org/r/1566531931-9772-6-git-send-email-hsin-hsiung.wang@mediatek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 27 Aug, 2019 8 commits
-
-
Jisheng Zhang authored
The differences between SY8824C and SY20278 are different regs for mode/enable. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163830.2c94f29b@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
SY20276 is an I2C-controlled adjustable voltage regulator made by Silergy Corp. The differences between SY8824C and SY20278 are different regs for mode/enable. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163754.170cf130@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
The differences between SY8824C and SY20276 are different vsel_min, vsel_step, vsel_count and regs for mode/enable. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163721.1947f7a0@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
SY20276 is an I2C-controlled adjustable voltage regulator made by Silergy Corp. The differences between SY8824C and SY20276 are different vsel_min, vsel_step, vsel_count and regs for mode/enable. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163650.47ed1213@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
The only difference between SY8824E and SY8824C/D is the vsel_min. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163537.52023c4e@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
SY8824E is an I2C-controlled adjustable voltage regulator made by Silergy Corp. The only difference between SY8824C and SY8824E is the vsel_min. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163505.361890af@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
SY8824C is an I2C attached single output regulator made by Silergy Corp, which is used on several Synaptics berlin platforms to control the power supply of the ARM cores. Add a driver for it. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163418.1a32fc48@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jisheng Zhang authored
SY8824C is an I2C-controlled adjustable voltage regulator made by Silergy Corp. Add its device tree binding. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190827163341.61df63a7@xhacker.debianSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 15 Aug, 2019 4 commits
-
-
Raag Jadav authored
Implement ->set_mode(), ->get_mode() and ->set_suspend_xx() hooks for act8865 with unlocked expert registers. Based on work done by Borris Brezillon on [1]. [1] https://www.spinics.net/lists/kernel/msg2942960.htmlSigned-off-by: Raag Jadav <raagjadav@gmail.com> Link: https://lore.kernel.org/r/1565721176-8955-2-git-send-email-raagjadav@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Nishka Dasgupta authored
In function of_get_child_regulator(), the loop for_each_child_of_node() contains two mid-loop return statements, each preceded by a statement putting child. In order to reduce this repetition, create a new label, err_node_put, that puts child and then returns the required value; edit the mid-loop return blocks to instead go to this new label. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190815053704.32156-1-nishkadg.linux@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Raag Jadav authored
Add documentation for act8865 regulator modes and suspend states. Add active-semi,8865-regulator.h file for device tree binding constants for act8865 regulators. Signed-off-by: Raag Jadav <raagjadav@gmail.com> Link: https://lore.kernel.org/r/1565721176-8955-3-git-send-email-raagjadav@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Colin Ian King authored
Variable ret is initialized to a value that is never read before a return statement and hence can be removed. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20190813133114.14931-1-colin.king@canonical.comSigned-off-by: Mark Brown <broonie@kernel.org>
-