max597x is hot swap controller.
This regulator driver controls the same & also configures fault
protection features supported by the chip.
Signed-off-by: NPatrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: NMarcello Sylvester Bauer <sylv@sylv.io>
Signed-off-by: NNaresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20220705122244.472894-4-Naresh.Solanki@9elements.comSigned-off-by: NMark Brown <broonie@kernel.org>

In scmi_regulator_probe(), of_find_node_by_name() will decrease
the refcount of its first argument and we need a of_node_get()
to keep reference balance.
Signed-off-by: NLiang He <windhl@126.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20220622034816.4094043-1-windhl@126.comSigned-off-by: NMark Brown <broonie@kernel.org>

The set of regulators available in the PM8909 PMIC is similar to PM8916
which is already supported by the driver. s3, s4 and l16 are missing.
However, probing the SPMI hardware identification registers using the
qcom_spmi-regulator driver reveals that the regulators in PM8909 are
actually some kind of mixture between PM8916 and PM8226:

  - ult_lo_smps (= pm8916_buck_lvo_smps): s1
  - ult_ho_smps (= pm8916_buck_hvo_smps): s2
  - ult_nldo (= pm8916_nldo): l1, l2, l3, l10
  - ult_pldo (= pm8916_pldo): l4, l8, l9, l12-l15, l17, l18
  - pldo (= pm8226_pldo): l5, l6, l7, l11

Use this mapping to add the rpm_regulator_data for PM8909 by reusing
the existing regulator definitions.
Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20220623094614.1410180-4-stephan.gerhold@kernkonzept.comSigned-off-by: NMark Brown <broonie@kernel.org>

The PM8916 device specification [1] documents a programmable range of
1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This
range is also used when controlling the regulator directly using the
qcom_spmi-regulator driver ("ult_pldo" there).

However, for some reason the qcom_smd-regulator driver allows a much
larger range for the same hardware component. This could be simply a
typo, since the start of the range is essentially just missing a '1'.

In practice this does not cause any major problems, since the driver
just sends the actual voltage to the RPM firmware instead of making use
of the incorrect voltage selector. Still, having the wrong range there
is confusing and prevents the regulator core from validating requests
correctly.

[1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf

Fixes: 57d65676 ("regulator: qcom-smd: Add PM8916 support")
Signed-off-by: NStephan Gerhold <stephan.gerhold@kernkonzept.com>
Link: https://lore.kernel.org/r/20220623094614.1410180-2-stephan.gerhold@kernkonzept.comSigned-off-by: NMark Brown <broonie@kernel.org>

'platform_device_id' struct is defined in 'mod_devicetable.h'.
Even 'of.h' also includes this header usage. The 'of.h' cannot be removed
due to 'of_match_ptr' function.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/1656466861-7737-2-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

From the common binding, 'enable-gpio' or 'enable-gpios' are all well
for external 'enable' gpio.

'gpiod_get_from_of_node' only parse the 'enable' property, it need to
add the gpio suffix. It's more convenient to use fwnode_gpiod_get_index.
Although fwnode parsing is not preferred, but 'of_parse_cb' already can
guarantee the callback will only be used by regulator of_node parsing.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1656466861-7737-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add mt6370 DisplayBias and VibLDO support.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/20220623115631.22209-10-peterwu.pub@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Add RT5120 PMIC regulator support.

It integrates 4 buck convertes, 1 LDO voltage regulator, 1 external
enable signal to control the external power source.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1655892104-10874-4-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

backlight_properties.fb_blank is deprecated. The states it represents
are handled by other properties; but instead of accessing those
properties directly, drivers should use the helpers provided by
backlight.h.

Instead of retrieving the backlight brightness in struct
backlight_properties manually, and then checking whether the backlight
should be on at all, use backlight_get_brightness() which does all
this and insulates this from future changes.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220607185304.1128962-1-steve@sk2.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add the get_voltage OP to MP5496 ops using the generic rpm_reg_get_voltage.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20220604193300.125758-1-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently set MP5496 Buck and LDO ranges dont match its datasheet[1].
According to the datasheet:
Buck range is 0.6-2.1875V with a 12.5mV step
LDO range is 0.8-3.975V with a 25mV step.

So, correct the ranges according to the datasheet[1].

[1] https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP5496GR/document_id/6906/Signed-off-by: NRobert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20220604193300.125758-2-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Driver does not seem to utilize anything from the kernel.h, compiles
and works fine for me without it.

So remove kernel.h include as it pulls in a lot of unused stuff.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Cc: christophe.jaillet@wanadoo.fr
Link: https://lore.kernel.org/r/20220607124759.775133-1-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

If the node for the match name cannot be found, 'of_regulator_match' will
returns init_data as NULL for this regulator.

Add the check for the init_data. If it's NULL, make 'rt5190a_of_parse_cb'
function directly return.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1654148646-12182-1-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

MP5496 is the updated version of MP5416 with the only difference being
that now all Buck regulators have the same 0.6-2.1875V range with a 12.5mV
step.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Acked-by: NSaravanan Sekar <sravanhome@gmail.com>
Link: https://lore.kernel.org/r/20220604145816.47576-4-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

In preparation for adding support for MP5496 which slightly differs from
MP5416 convert the driver to use OF match data instead of always using the
MP5416 regulator_desc for regulator registration.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Acked-by: NSaravanan Sekar <sravanhome@gmail.com>
Link: https://lore.kernel.org/r/20220604145816.47576-3-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Sort the header include list alphabetically.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20220604145816.47576-2-robimarko@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NDmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

of_find_node_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.

Fixes: 0fbeae70 ("regulator: add SCMI driver")
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220516074433.32433-1-linmq006@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

of_node_get() returns a node with refcount incremented.
Calling of_node_put() to drop the reference when not needed anymore.

Fixes: 3784b6d6 ("regulator: pfuze100: add pfuze100 regulator driver")
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220511113506.45185-1-linmq006@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Following changes have been made:

- S5, L4, L18, L20 and L21 were removed (S5 is managed by
SPMI, whereas the rest seems not to exist [or at least it's blocked
by Sony Loire /MSM8956/ RPM firmware])

- Supply maps have were adjusted to reflect regulator changes.

Fixes: e44adca5 ("regulator: qcom_smd: Add PM8950 regulators")
Signed-off-by: NKonrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20220430163753.609909-1-konrad.dybcio@somainline.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Since the introduction of regulator->enable_count, a driver that did
an exclusive get on an already-enabled regulator would end up with
enable_count initialized to 0 but rdev->use_count initialized to 1.
With that starting point the regulator is effectively stuck enabled,
because if the driver attempted to disable it it would fail the
enable_count underflow check in _regulator_handle_consumer_disable().

The EXCLUSIVE_GET path in _regulator_get() now initializes
enable_count along with rdev->use_count so that the regulator can be
disabled without underflowing the former.
Signed-off-by: NZev Weiss <zev@bewilderbeest.net>
Fixes: 5451781d ("regulator: core: Only count load for enabled consumers")
Link: https://lore.kernel.org/r/20220505043152.12933-1-zev@bewilderbeest.netSigned-off-by: NMark Brown <broonie@kernel.org>

If a regulator provides a get_error_flags() operation, its sysfs
attributes will now include an entry for each defined
REGULATOR_ERROR_* flag.
Signed-off-by: NZev Weiss <zev@bewilderbeest.net>
Link: https://lore.kernel.org/r/20220504065252.6955-3-zev@bewilderbeest.netSigned-off-by: NMark Brown <broonie@kernel.org>

When DVS is enabled via the devicetree properties
"nxp,dvs-run-voltage" and "nxp,dvs-standby-voltage" then
also the bit that enables DVS control via PMIC_STBY_REQ pin
should be set.
Signed-off-by: NRickard x Andersson <rickaran@axis.com>
Link: https://lore.kernel.org/r/20220429072211.24957-5-rickaran@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>

The default configuration of the PMIC behavior makes the PMIC
power cycle most regulators on WDOG_B assertion. This power
cycling causes the memory contents of OCRAM to be lost.
Some systems neeeds some memory that survives reset and
reboot, therefore this patch is created.
Signed-off-by: NRickard x Andersson <rickaran@axis.com>
Link: https://lore.kernel.org/r/20220429072211.24957-4-rickaran@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>

Make the I2C Level Translator included in PCA9450 configurable from
devicetree. The reset state is off. By setting nxp,i2c-lt-enable, the
I2C Level Translator will be enabled while in STANDBY or RUN state.
Signed-off-by: NPer-Daniel Olsson <perdo@axis.com>
Signed-off-by: NRickard x Andersson <rickaran@axis.com>
Link: https://lore.kernel.org/r/20220429072211.24957-2-rickaran@axis.comSigned-off-by: NMark Brown <broonie@kernel.org>

Regulators block of SM5703 controls several voltage regulators which
are used to power various components. There are 3 LDO outputs ranging
from 1.5 to 3.3V, a buck regulator ranging from 1V to 3V, two fixed
voltage LDO regulators for powering the USB devices and one high-power
fixed voltage LDO line (actually two lines) meant to power high-power
USB devices.
Signed-off-by: NMarkuss Broks <markuss.broks@gmail.com>
Link: https://lore.kernel.org/r/20220423085319.483524-6-markuss.broks@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Having one enable-gpios property for all regulators is discouraged and
instead, similarly to regulator core ena_gpiod feature, each GPIO should
be present in each regulator node.  Add support for parsing such GPIOs,
keeping backwards compatibility.
Signed-off-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/20220425072455.27356-3-krzysztof.kozlowski@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>

These delays can be relatively large (e.g., hundreds of microseconds to
several milliseconds on RK3399 Gru systems). Per
Documentation/timers/timers-howto.rst, that should usually use a
sleeping delay. Let's use the existing regulator delay helper to handle
both large and small delays appropriately. This avoids burning a bunch
of CPU time and hurting scheduling latencies when hitting regulators a
lot (e.g., during cpufreq).

The sleep vs. delay issue choice has been made differently over time --
early versions of RK3399 Gru PWM-regulator support used usleep_range()
in pwm-regulator.c. More of this got moved into the regulator core,
in commits like:

73e705bf regulator: core: Add set_voltage_time op

At the same time, the sleep turned into a delay.

It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an
atomic context. (All our callers grab various mutexes already.)

I avoid using fsleep() because it uses a usleep_range() of [N to N*2],
and usleep_range() very commonly biases to the high end of the range. We
don't want to double the expected delay, especially for long delays.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

I want to use it in other contexts besides _regulator_do_enable().
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220420141511.v2.1.I31ef0014c9597d53722ab513890f839f357fdfb3@changeidSigned-off-by: NMark Brown <broonie@kernel.org>

KASAN report slab-out-of-bounds in __regmap_init as follows:

BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841
Read of size 1 at addr ffff88803678cdf1 by task xrun/9137

CPU: 0 PID: 9137 Comm: xrun Tainted: G        W         5.18.0-rc2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88
 print_report.cold+0xcd/0x69b mm/kasan/report.c:313
 kasan_report+0x8e/0xc0 mm/kasan/report.c:491
 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841
 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266
 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394
 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039
 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563

This happend when da9121 device is probe by da9121_i2c_id, but with
invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later
da9121_assign_chip_model() will access 'regmap' without init it.

Fix it by return -EINVAL from da9121_assign_chip_model() if
'chip->subvariant_id' is invalid.

Fixes: f3fbd556 ("regulator: da9121: Add device variants")
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NAdam Ward <Adam.Ward.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20220421090335.1876149-1-weiyongjun1@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Using pm_runtime_resume_and_get is more appropriate
for simplifing code
Reported-by: NZeal Robot <zealci@zte.com.cn>
Signed-off-by: NMinghao Chi <chi.minghao@zte.com.cn>
Link: https://lore.kernel.org/r/20220412071030.2532230-1-chi.minghao@zte.com.cnSigned-off-by: NMark Brown <broonie@kernel.org>

GPIO library does copy the of_node from the parent device of
the GPIO chip, there is no need to repeat this in the individual
drivers. Remove these assignment all at once.

For the details one may look into the of_gpio_dev_init() implementation.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20220325184508.45670-1-andriy.shevchenko@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The MT6366 is a regulator found on boards based on MediaTek MT8186 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: NJohnson Wang <johnson.wang@mediatek.com>
Link: https://lore.kernel.org/r/20220401080212.27383-2-johnson.wang@mediatek.comSigned-off-by: NMark Brown <broonie@kernel.org>

Without active_discharge_on setting, the SWITCH1 discharge enable control
is always disabled. Fix it.

Fixes: 3b15ccac ("regulator: Add regulator driver for ATC260x PMICs")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20220403132235.123727-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

While we currently assume that regulators with no control available are
just uncontionally enabled this isn't always as clearly displayed to
users as is desirable, for example the code for disabling unused
regulators will log that it is about to disable them. Clean this up a
bit by setting always_on during constraint evaluation if we have no
available mechanism for controlling the regualtor so things that check
the constraint will do the right thing.
Signed-off-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220325144637.1543496-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

OOMs are very verbose, we don't need to print an additional error message
when we fail to allocate.
Signed-off-by: NMark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220324201854.3107077-1-broonie@kernel.orgSigned-off-by: NMark Brown <broonie@kernel.org>

Add support for Richtek RT5759 high-performance DCDC converter.
Signed-off-by: NChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1648294788-11758-3-git-send-email-u0084500@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The MT6366 is a regulator found on boards based on MediaTek MT8186 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NJohnson Wang <johnson.wang@mediatek.com>
Reviewed-by: NAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220317030402.24894-2-johnson.wang@mediatek.comSigned-off-by: NMark Brown <broonie@kernel.org>

The active_discharge_on setting was missed, so output discharge resistor
is always disabled. Fix it.

Fixes: 0555d414 ("regulator: rtq2134: Add support for Richtek RTQ2134 SubPMIC")
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20220404022514.449231-1-axel.lin@ingics.comSigned-off-by: NMark Brown <broonie@kernel.org>

As per Table 130 of the wm8994 datasheet at [1], there is an off-on
delay for LDO1 and LDO2.  In the wm8958 datasheet [2], I could not
find any reference to it.  I could not find a wm1811 datasheet to
double-check there, but as no one has complained presumably it works
without it.

This solves the issue on Samsung Aries boards with a wm8994 where
register writes fail when the device is powered off and back-on
quickly.

[1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf
[2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdfSigned-off-by: NJonathan Bakker <xc-racer2@live.ca>
Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/CY4PR04MB056771CFB80DC447C30D5A31CB1D9@CY4PR04MB0567.namprd04.prod.outlook.comSigned-off-by: NMark Brown <broonie@kernel.org>