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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190910170246.GA56792@dtor-wsSigned-off-by: NMark Brown <broonie@kernel.org>

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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190910170050.GA55530@dtor-wsSigned-off-by: NMark Brown <broonie@kernel.org>

Pro5 SoC has same scheme of USB3 VBUS as Pro4, so the data for Pro5 is
equivalent to Pro4.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1568080304-1572-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPhilippe Schenker <philippe.schenker@toradex.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20190910062103.39641-4-philippe.schenker@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NPhilippe Schenker <philippe.schenker@toradex.com>
Link: https://lore.kernel.org/r/20190910062103.39641-2-philippe.schenker@toradex.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NKrzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20190909155723.24734-1-krzk@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

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: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20190908035720.17748-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20190904214200.GA66118@dtor-wsSigned-off-by: NMark Brown <broonie@kernel.org>

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: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190906130632.6709-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NGuido Günther <agx@sigxcpu.org>
Link: https://lore.kernel.org/r/363bd50cc7c60daa57d614a341d1fd649f05194c.1567625660.git.agx@sigxcpu.orgSigned-off-by: NMark Brown <broonie@kernel.org>

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: NMark Brown <broonie@kernel.org>
Tested-by: NLee Jones <lee.jones@linaro.org>
Cc: stable@vger.kernel.org

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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20190902151332.28058-1-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

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: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20190830071740.4267-2-brgl@bgdev.plSigned-off-by: NMark Brown <broonie@kernel.org>

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: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20190829125435.48770-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add prefixes to BUCK_EN and MODE macros to namespace them.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190829143927.395d0385@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

Update the entire comment block to be C++ style so it looks consistent.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190829143749.4b42bc65@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMark Brown <broonie@kernel.org>

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: NHsin-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: NMark Brown <broonie@kernel.org>

add dt-binding document for MediaTek MT6358 PMIC
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHsin-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: NMark Brown <broonie@kernel.org>

The differences between SY8824C and SY20278 are different regs
for mode/enable.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163830.2c94f29b@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

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: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163754.170cf130@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

The differences between SY8824C and SY20276 are different vsel_min,
vsel_step, vsel_count and regs for mode/enable.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163721.1947f7a0@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

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: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163650.47ed1213@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

The only difference between SY8824E and SY8824C/D is the vsel_min.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163537.52023c4e@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

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: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163505.361890af@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

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: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163418.1a32fc48@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

SY8824C is an I2C-controlled adjustable voltage regulator made by
Silergy Corp.

Add its device tree binding.
Signed-off-by: NJisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20190827163341.61df63a7@xhacker.debianSigned-off-by: NMark Brown <broonie@kernel.org>

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: NRaag Jadav <raagjadav@gmail.com>
Link: https://lore.kernel.org/r/1565721176-8955-2-git-send-email-raagjadav@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NNishka Dasgupta <nishkadg.linux@gmail.com>
Link: https://lore.kernel.org/r/20190815053704.32156-1-nishkadg.linux@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NRaag Jadav <raagjadav@gmail.com>
Link: https://lore.kernel.org/r/1565721176-8955-3-git-send-email-raagjadav@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

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: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20190813133114.14931-1-colin.king@canonical.comSigned-off-by: NMark Brown <broonie@kernel.org>

_opp_supported_by_regulators() wrongly ignored errors from
regulator_is_supported_voltage(), so it considered errors as
success. Since
commit 49820944 ("regulator: core: simplify return value on suported_voltage")
regulator_is_supported_voltage() returns a real boolean, so
errors make _opp_supported_by_regulators() return false.

That reveals a problem with the declaration of the VDD1/2
regulators on twl4030.
The VDD1/VDD2 regulators on twl4030 are neither defined with
voltage lists nor with the continuous flag set, so
regulator_is_supported_voltage() returns false and an error
before above mentioned commit (which was considered success)
The result is that after the above mentioned commit cpufreq
does not work properly e.g. dm3730.

[    2.490997] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV: 1012500, not supported by regulator
[    2.501617] cpu cpu0: _opp_add: OPP not supported by regulators (300000000)
[    2.509246] core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator
[    2.519775] cpu cpu0: _opp_add: OPP not supported by regulators (600000000)
[    2.527313] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV: 1325000, not supported by regulator
[    2.537750] cpu cpu0: _opp_add: OPP not supported by regulators (800000000)

The patch fixes declaration of VDD1/2 regulators by
adding proper voltage lists.

Fixes: 49820944 ("regulator: core: simplify return value on suported_voltage")
Cc: stable@vger.kernel.org
Signed-off-by: NAndreas Kemnade <andreas@kemnade.info>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Link: https://lore.kernel.org/r/20190814214319.24087-1-andreas@kemnade.infoSigned-off-by: NMark Brown <broonie@kernel.org>

According to ACT8945A datasheet[1], operating modes for ldos are
controlled by BIT(5) of their respective _CTRL registers.

[1] https://active-semi.com/wp-content/uploads/ACT8945A_Datasheet.pdf

Fixes: 7482d6ec ("regulator: act8945a-regulator: Implement PM functionalities")
Signed-off-by: NRaag Jadav <raagjadav@gmail.com>
Link: https://lore.kernel.org/r/1565635194-5816-1-git-send-email-raagjadav@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

During reset the VMMC regulator doesn't reach 0V and only drops to
1.8V, furthermore the pulse width is under 200us whereas the SD
specification expect 1ms.

The WR_S bit allows the TWL6030 to no reset at all the VMMC during warm
reset and keep the current voltage. Thanks to this workaround the SD
card doesn't reach a undefined reset stage.

Actually this behavior is available for all the LDO regulator, so the
driver will also allow to use it with any of these regulator.
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20190725094542.16547-4-gregory.clement@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>

Instead of refering the full pdev->dev.of_node use a local variable.
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20190725094542.16547-3-gregory.clement@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>

During reset the VMMC regulator doesn't reach 0V and only drops to
1.8V, furthermore the pulse width is under 200us whereas the SD
specification expect 1ms.

For this 2 reasons being able to no reset at all the VMMC during warm
reset and keep the current voltage is a good workaround. The TWL6030
allows this but needs to be aware of it and this configuration should
also be shared with the bootloader.

This is the purpose of this new property: ti,retain-on-reset
Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
Link: https://lore.kernel.org/r/20190725094542.16547-2-gregory.clement@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add the PMIC5 modes and use them pmic5 ldo and smps
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20190809073616.1235-4-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

pmic5_bob voltages count is 136 [0,135] so update it
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20190809073616.1235-3-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

It helps to keep sorted order for compatibles, so sort them
Suggested-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NVinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20190809073616.1235-2-vkoul@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>