summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2020-11-13regulator: debug early supply resolvingMichał Mirosław
Help debugging the case when set_machine_constraints() needs to be repeated. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/f9cba575580369e46661a9278ee6c6a8d8564c2a.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: workaround self-referent regulatorsMichał Mirosław
Workaround regulators whose supply name happens to be the same as its own name. This fixes boards that used to work before the early supply resolving was removed. The error message is left in place so that offending drivers can be detected. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: avoid resolve_supply() infinite recursionMichał Mirosław
When a regulator's name equals its supply's name the regulator_resolve_supply() recurses indefinitely. Add a check so that debugging the problem is easier. The "fixed" commit just exposed the problem. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Reported-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-13regulator: fix memory leak with repeated set_machine_constraints()Michał Mirosław
Fixed commit introduced a possible second call to set_machine_constraints() and that allocates memory for rdev->constraints. Move the allocation to the caller so it's easier to manage and done once. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # stpmic1 Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-11Merge branch 'for-5.10' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.11
2020-11-11regulator: pfuze100: limit pfuze-support-disable-sw to pfuze{100,200}Sean Nyekjaer
Limit the fsl,pfuze-support-disable-sw to the pfuze100 and pfuze200 variants. When enabling fsl,pfuze-support-disable-sw and using a pfuze3000 or pfuze3001, the driver would choose pfuze100_sw_disable_regulator_ops instead of the newly introduced and correct pfuze3000_sw_regulator_ops. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Fixes: 6f1cf5257acc ("regualtor: pfuze100: correct sw1a/sw2 on pfuze3000") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201110174113.2066534-1-sean@geanix.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-10Merge series "regulator: bd718x7: support voltage scaling" from Matti ↵Mark Brown
Vaittinen <matti.vaittinen@fi.rohmeurope.com>: RFC for adding a support for typical voltage scaling connection In few occasions there has been a need to scale the voltage output from bucks on BD71837. Usually this is done when buck8 is used to power specific GPU which can utilize voltages down to 0.7V. As lowest the buck8 on BD71837 can go is 0.8V, and external connection is used to scale the voltages. The BD71837, BD71847 and BD71850 bucks can be adjusted by pulling up the feedback pin using suitable voltage/resistors. |---------------| | buck 8 |-------+----->Vout | | | |---------------| | | | | | +-------+--R2----+ | R1 | V FB-pull-up This will scale the voltage as follows: - Vout_o = Vo - (Vpu - Vo)*R2/R1 - Linear_step = step_orig*(R1+R2)/R1 where: Vout_o is adjusted voltage output at vsel reg value 0 Vo is original voltage output at vsel reg value 0 Vpu is the pull-up voltage V FB-pull-up in the picture R1 and R2 are resistor values. >From HW point of view this does not need to be limited to buck 8. This connection can be used to adjust output from any of the bucks on BD71837/47/50. As this seems to be a 'de-facto' way to scale the voltages on BD71837 it might be a good idea to support computing the new voltage ranges for bucks based on the V-pull-up and resistor R1/R2 values given from device-tree. This allows describing the external HW connection using DT to correctly scale the voltages. This RFC uses "rohm,feedback-pull-up-r1-ohms" and "rohm,feedback-pull-up-r2-ohms" to provide the resistor values - but these names (without the picture) might not be too descriptive. I am grateful for all suggestions as better and more descriptive names. This patch series is an RFC because this connection feels somewhat "hacky". OTOH - when hack becomes widely used, it is less of an hack and more of a standard - and occasionally supporting HW hacks using SW may benefit us all, right? :) The other thing some projects do is allowing the change of BD71837 buck8 voltages when buck8 is enabled. This however will introduce voltage spikes as buck8 was not originally designed for this. The specific HW platform must be evaluated to be able to tolerate these spikes. Thus this patch series does not support buck8 voltage changes when buck8 is enabled. I wonder if this should be allowed per some config option(?) I don't want to help people frying their boards... Opinions? Is there suggested way of allowing this type of features at own risk? Config or even Some #ifdef which is not listed in Kconfig? Device-tree property? If you have (good) suggestions I could add the optional (non default) DVS support for non DVS bucks on BD71837. Matti Vaittinen (3): dt-bindings: regulator: BD71837 support commonly used feedback connection dt-bindings: regulator: BD71847 support commonly used feedback connection regulator: bd718x7: Support external connection to scale voltages .../regulator/rohm,bd71837-regulator.yaml | 48 +++++ .../regulator/rohm,bd71847-regulator.yaml | 49 ++++++ drivers/regulator/bd718x7-regulator.c | 164 +++++++++++++++++- 3 files changed, 254 insertions(+), 7 deletions(-) base-commit: 3cea11cd5e3b00d91caf0b4730194039b45c5891 -- 2.21.3 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
2020-11-10regulator: bd718x7: Support external connection to scale voltagesMatti Vaittinen
Setups where regulator (especially the buck8) output voltage is scaled by adding external connection where some other regulator output is connected to feedback-pin (over suitable resistors) is getting popular amongst users of BD71837. This allows for example scaling down the buck8 voltages to suit lover GPU voltages for projects where buck8 is (ab)used to supply power for GPU. As a note - some setups do allow DVS for buck8. This do produce voltage spikes and the HW must be evaluated to be able to survive them. Thus this commit still keep the DVS disabled for non DVS bucks by default. Let's not help you burn your proto board. Allow describing this external connection from DT and scale the voltages accordingly. This is what the connection should look like: |------------| | buck 8 |-------+----->Vout | | | |------------| | | FB pin | | | +-------+--R2---+ | R1 | V FB-pull-up Here the buck output is sifted according to formula: Vout_o = Vo - (Vpu - Vo)*R2/R1 Linear_step = step_orig*(R1+R2)/R1 where: Vout_o is adjusted voltage output at vsel reg value 0 Vo is original voltage output at vsel reg value 0 Vpu is the pull-up voltage V FB-pull-up in the picture R1 and R2 are resistor values. Bring support for specifying the Vpu, R1 and R2 from device tree and scale voltages if they are given. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/89b2be87074f307a8823f15f34e1f662023cbf36.1604994184.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-10regulator: core: don't disable regulator if is_enabled return error.Pi-Hsun Shih
In regulator_late_cleanup when is_enabled failed, don't try to disable the regulator since it would likely to fail too and causing confusing error messages. Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Link: https://lore.kernel.org/r/20201106064817.3290927-1-pihsun@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-03regulator: Add support for DA9121 regulatorVincent Whitchurch
Add support for the Dialog Semiconductor DA9121, a single-channel dual-phase buck converter controlled via I2C. Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Link: https://lore.kernel.org/r/20201103100021.19603-3-vincent.whitchurch@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-03regulator: defer probe when trying to get voltage from unresolved supplyMichał Mirosław
regulator_get_voltage_rdev() is called in regulator probe() when applying machine constraints. The "fixed" commit exposed the problem that non-bypassed regulators can forward the request to its parent (like bypassed ones) supply. Return -EPROBE_DEFER when the supply is expected but not resolved yet. Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator") Cc: stable@vger.kernel.org Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reported-by: Ondřej Jirman <megous@megous.com> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com> Tested-by: Ondřej Jirman <megous@megous.com> Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-28regulator: fix a kernel-doc markupMauro Carvalho Chehab
It seems that the function was renamed. kernel-doc markup should follow it. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/dffad16d4d6427d7d0fc89797e4126fe7c69d5de.1603469755.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-26Merge series " [PATCH v2 0/5]" from Dmitry Baryshkov ↵Mark Brown
<dmitry.baryshkov@linaro.org>: On SM8250 MDSS_GDSC (and the rest of display clock controller) is supplied power by MMCX power domain. Handle this link in GDSC code by binding the power domain in dts file. This patchset depends on [1] Changes since v1: - Define fixed-regulator-domain regulator using power domain performance state for enabling/disabling. - Rework to use new fixed regulator type (fixed-regulator-domain) instead of controlling power domain directly from gdsc code. Changes since RFC: - Fix naming of gdsc_supply_on/gdsc_supply_off functions - Fix detaching of solo gdsc's power domain in error handling code - Drop the dts patch, as respective display nodes are still not submitted to the mailing list. [1] https://lore.kernel.org/linux-arm-msm/20200927190653.13876-1-jonathan@marek.ca/
2020-10-26regulator: lp872x: make a const array static, makes object smallerColin Ian King
Don't populate const array lp872x_num_regulators on the stack but instead make it static. Makes the object code smaller by 29 bytes. Before: text data bss dec hex filename 18441 4624 64 23129 5a59 drivers/regulator/lp872x.o After: text data bss dec hex filename 18316 4720 64 23100 5a3c drivers/regulator/lp872x.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201016222235.686981-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-26regulator: fixed: support using power domain for enable/disableDmitry Baryshkov
Adds possibility to choose the compatible "fixed-regulator-domain" for regulators which use power domain for enabling/disabling corresponding regulator. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20201023131925.334864-3-dmitry.baryshkov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05Merge remote-tracking branch 'regulator/for-5.10' into regulator-nextMark Brown
2020-10-05regulator: bd9576: Fix printMatti Vaittinen
The print in probe is done using pr_info. Correct print call would be dev_dbg because: - Severity should really be dbg - The dev pointer is given as first argument Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/c4f55add237455555df0597c72052022f7a669f6.1601885841.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05regulator: qcom_smd: add pm8953 regulatorsVladimir Lypak
The PM8953 is commonly used on board with MSM8953 SoCs or its variants: APQ8053, SDM(SDA)450 and SDM(SDA)632. It provides 7 SMPS and 23 LDO regulators. Signed-off-by: Vladimir Lypak <junak.pub@gmail.com> Link: https://lore.kernel.org/r/20201004083413.324351-1-junak.pub@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05regulator: Make constraint debug processing conditional on DEBUGGeert Uytterhoeven
If debugging is disabled, print_constraints() does not print the actual constraints, but still performs some processing and string formatting, only to throw away the result later. Fix this by moving all constraint debug processing to a separate function, and replacing it by a dummy when debugging is disabled. This reduces kernel size by almost 800 bytes (on arm/arm64). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201005131546.22448-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01Merge series "Support for PM660/PM660L SPMI and SMD regulators" from ↵Mark Brown
kholk11@gmail.com AngeloGioacchino Del Regno <kholk11@gmail.com>: From: AngeloGioacchino Del Regno <kholk11@gmail.com> This patch series enables support for the regulators as found in the PM660 and PM660L PMICs. While at it, and to make them work, along with other regulators for other qcom PMICs, enlarge the maximum property name length in the regulator core, so that we're able to correctly parse the supply parents, which have got very long names (details in patch 1/5). This patch series has been tested against the following devices: - Sony Xperia XA2 Ultra (SDM630 Nile Discovery) - Sony Xperia 10 (SDM630 Ganges Kirin) - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) AngeloGioacchino Del Regno (7): regulator: core: Enlarge max OF property name length to 64 chars regulator: qcom_spmi: Add support for new regulator types regulator: qcom_spmi: Add PM660/PM660L regulators regulator: dt-bindings: Document the PM660/660L SPMI PMIC entries regulator: qcom_smd: Add PM660/PM660L regulator support mfd: qcom-spmi-pmic: Add support for PM660/PM660L regulator: dt-bindings: Document the PM660/PM660L PMICs entries .../regulator/qcom,smd-rpm-regulator.yaml | 7 ++ .../regulator/qcom,spmi-regulator.txt | 31 +++++ drivers/mfd/qcom-spmi-pmic.c | 4 + drivers/regulator/core.c | 4 +- drivers/regulator/qcom_smd-regulator.c | 113 ++++++++++++++++++ drivers/regulator/qcom_spmi-regulator.c | 107 +++++++++++++++++ include/linux/soc/qcom/smd-rpm.h | 4 + 7 files changed, 268 insertions(+), 2 deletions(-) -- 2.28.0
2020-10-01regulator: qcom: labibb: Constify static structsRikard Falkeborn
The only usage of qcom_labibb_ops is to assign it to the ops field in the regulator_desc struct, which is a const pointer. The only usage of pmi8998_lab_desc and pmi8998_ibb_desc is to assign their address to the desc field in the labibb_regulator_data struct which can be made const, since it is only copied into the desc field in the labbibb_regulator_data struct. This struct is modified, but that's a copy of the static one. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200930162602.18583-1-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_smd: Add PM660/PM660L regulator supportAngeloGioacchino Del Regno
The PM660 and PM660L are a very very common PMIC combo, found on boards using the SDM630, SDM636, SDM660 (and SDA variants) SoC. PM660 provides 6 SMPS and 19 LDOs (of which one is unaccesible), while PM660L provides 5 SMPS (of which S3 and S4 are combined), 10 LDOs and a Buck-or-Boost (BoB) regulator. The PM660L IC also provides other regulators that are very specialized (for example, for the display) and will be managed in the other appropriate drivers (for example, labibb). Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-6-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_spmi: Add PM660/PM660L regulatorsAngeloGioacchino Del Regno
The PM660 PMIC is very often paired with the PM660L option on SDM630/663/660 (and SDA variants) boards. The PM660 has 11 "660" LDOs (2 NMOS, 9 PMOS) and 7 HT LDOs (4 NMOS, 3 PMOS) and a quirk: the L4 regulator is unaccessible or does not exist on the PMIC. The PM660L has 8 "660" LDOs (1 NMOS, 7 PMOS) and 2 HT NMOS LDOs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-4-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: qcom_spmi: Add support for new regulator typesAngeloGioacchino Del Regno
This commit adds the support for some regulator types that are missing in this driver, such as the ht nmos-ldo, ht-lv nmos-ldo and new gen n/pmos-ldo, all belonging to the FTSMPS426 register layout. This is done in preparation for adding support for the PM660 and PM660L PMICs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-3-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: core: Enlarge max OF property name length to 64 charsAngeloGioacchino Del Regno
Some regulator drivers may be defining very long names: this is the case with the qcom_smd and qcom_spmi regulators, where we need to parse the regulator parents from DT. For clarity, this is an example: { "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, "vdd_l8_l9_l10_l11_l12_l13_l14" }, pm660-regulators { ... vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04> ... }; Now, with a 32 characters limit, the function is trying to parse, exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of the right one, which is 37 chars long in this specific case. ... And this is not only the case with PM660/PM660L, but also with PMA8084, PM8916, PM8950 and others that are not implemented yet. The length of 64 chars was chosen based on the longest parsed property name that I could find, which is in PM8916, and would be 53 characters long. At that point, rounding that to 64 looked like being the best idea. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01regulator: tps65910: use regmap accessorsMichał Mirosław
Use regmap accessors directly for register manipulation - removing one layer of abstraction. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/e82886d0f8f5131c9fccf2a17e3a15acce507d6f.1601164493.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-30regulator: rtmv20: Add missing regcache cache only before marked as dirtyChiYuan Huang
Add missing regcache cache only before masked as dirty. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1601461132-15251-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-30regulator: rtmv20: Update DT binding document and property name parsingChiYuan Huang
1. Add vendor suffix to all proprietary properties. 2. Fix typo. 3. Change lsw to normal property, not pattern property. 4. Due to item 1, modify source code for property parsing. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1601460480-4259-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-28Merge series "regulator: debugging aids" from Michał Mirosław ↵Mark Brown
<mirq-linux@rere.qmqm.pl>: Three simple patches to aid in debugging regulators. Michał Mirosław (3): regulator: print state at boot regulator: print symbolic errors in kernel messages regulator: resolve supply after creating regulator drivers/regulator/core.c | 124 ++++++++++++++++++++++----------------- 1 file changed, 69 insertions(+), 55 deletions(-) -- 2.20.1
2020-09-28regulator: rtmv20: Adds support for Richtek RTMV20 load switch regulatorChiYuan Huang
Add support for Richtek RTMV20 load switch regulator. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1601277584-5526-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-28regulator: resolve supply after creating regulatorMichał Mirosław
When creating a new regulator its supply cannot create the sysfs link because the device is not yet published. Remove early supply resolving since it will be done later anyway. This makes the following error disappear and the symlinks get created instead. DCDC_REG1: supplied by VSYS VSYS: could not add device link regulator.3 err -2 Note: It doesn't fix the problem for bypassed regulators, though. Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators") Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-28regulator: print symbolic errors in kernel messagesMichał Mirosław
Change all error-printing messages to include error name via %pe instead of numeric error or nothing. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/1dcf25f39188882eb56918a9aa281ab17b792aa5.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-28regulator: print state at bootMichał Mirosław
Make the initial state of the regulator shown when debugging. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/53c4f3d394d68f0989174f89e3b0882cebbbd787.1601155770.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-25Merge tag 'regulator-fix-v5.9-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fix from Mark Brown: "A single fix for incorrect specification of some of the register fields on axp20x devices which would break voltage setting on affected systems" * tag 'regulator-fix-v5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: axp20x: fix LDO2/4 description
2020-09-23regulator: axp20x: fix LDO2/4 descriptionIcenowy Zheng
Currently we wrongly set the mask of value of LDO2/4 both to the mask of LDO2, and the LDO4 voltage configuration is left untouched. This leads to conflict when LDO2/4 are both in use. Fix this issue by setting different vsel_mask to both regulators. Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Link: https://lore.kernel.org/r/20200923005142.147135-1-icenowy@aosc.io Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-22regulator: s5m8767: initialize driver via module_platform_driverKrzysztof Kozlowski
The driver was using subsys_initcall() because in old times deferred probe was not supported everywhere and specific ordering was needed. Since probe deferral works fine and specific ordering is discouraged (hides dependencies between drivers and couples their boot order), the driver can be converted to regular module_platform_driver. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200921203616.19623-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-22regulator: enable compile testing for Maxim and Samsung PMIC driversKrzysztof Kozlowski
Most of Maxim and Samsung PMIC/MUIC regulator drivers can be compile tested to increase build coverage. This allows to build them on configurations without I2C (as I2C is required by dependency - parent MFD driver). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200920214107.6299-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-22regulator: fix indentation issueColin Ian King
There is a return statement that is indented with an extra space, fix this by removing it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200920142454.33352-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-21regulator: unexport regulator_lock/unlock()Michał Mirosław
regulator_lock/unlock() was used only to guard regulator_notifier_call_chain(). As no users remain, make the functions internal. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/d3381aabd2632aff5e7b839d55868bec6e85c811.1600550732.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-17Merge series "Support ROHM BD9576MUF and BD9573MUF PMICs" from Matti ↵Mark Brown
Vaittinen <matti.vaittinen@fi.rohmeurope.com>: Initial support for ROHM BD9576MUF and BD9573MUF PMICs. These PMICs are primarily intended to be used to power the R-Car family processors. BD9576MUF includes some additional safety features the BD9573MUF does not have. This initial version of drivers does not utilize these features and for now the SW behaviour is identical. Please note that this version of drivers is only tested on BD9576MUF but according to the data-sheets the relevant parts of registers should be same so drivers should also work on BD9573MUF. This patch series includes MFD, watchdog and regulator drivers with basic functionality such as: - Enabling and pinging the watchdog - configuring watchog timeout / window from device-tree - reading regulator states/voltages - enabling/disabling VOUT1 (VD50) when control mode B is used. This patch series does not bring interrupt support. BD9576MUF and BD9573MUF are designed to keep the IRQ line low for whole duration of error condition. IRQ can't be 'acked'. So proper IRQ support would require some IRQ limiter implementation (delayed unmask?) in order to not hog the CPU. --- Matti Vaittinen (6): dt_bindings: mfd: Add ROHM BD9576MUF and BD9573MUF PMICs dt_bindings: regulator: Add ROHM BD9576MUF and BD9573MUF PMICs mfd: Support ROHM BD9576MUF and BD9573MUF wdt: Support wdt on ROHM BD9576MUF and BD9573MUF regulator: Support ROHM BD9576MUF and BD9573MUF MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers .../bindings/mfd/rohm,bd9576-pmic.yaml | 129 +++++++ .../regulator/rohm,bd9576-regulator.yaml | 33 ++ MAINTAINERS | 4 + drivers/mfd/Kconfig | 11 + drivers/mfd/Makefile | 1 + drivers/mfd/rohm-bd9576.c | 130 +++++++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile | 1 + drivers/regulator/bd9576-regulator.c | 337 ++++++++++++++++++ drivers/watchdog/Kconfig | 13 + drivers/watchdog/Makefile | 1 + drivers/watchdog/bd9576_wdt.c | 295 +++++++++++++++ include/linux/mfd/rohm-bd957x.h | 61 ++++ include/linux/mfd/rohm-generic.h | 2 + 14 files changed, 1028 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd9576-pmic.yaml create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml create mode 100644 drivers/mfd/rohm-bd9576.c create mode 100644 drivers/regulator/bd9576-regulator.c create mode 100644 drivers/watchdog/bd9576_wdt.c create mode 100644 include/linux/mfd/rohm-bd957x.h base-commit: f4d51dffc6c01a9e94650d95ce0104964f8ae822 -- 2.21.0 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
2020-09-17regulator: Support ROHM BD9576MUF and BD9573MUFMatti Vaittinen
Add initial support for ROHM BD9576MUF and BD9573MUF PMICs regulators. These PMICs are mainly used to power the R-Car series processors. The BD9576 includes some functional-safety features which are not present on BD9573. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/78baea1d7922506827ca717e277e4e6b391bbb78.1600329307.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-14regulator: ti-abb: Constify ti_abb_reg_opsRikard Falkeborn
The only usage of ti_abb_reg_ops is to assign its address to the ops field in the regulator_desc struct, which is a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-6-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-14regulator: pca9450: Constify static regulator_opsRikard Falkeborn
The only usages of these is to assign their address to the ops field in the regulator_desc struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-5-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-14regulator: stw481x-vmmc: Constify static structsRikard Falkeborn
The only usage of stw481x_vmmc_ops is to assign its address to the ops field in the regulator_desc struct which is a const pointer. The only usage of vmmc_regulator is to pass its address to of_get_regulator_init_data() and devm_regulator_register(), both which take const pointers. Make both of them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-4-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-14regulator: fixed: Constify static regulator_opsRikard Falkeborn
The only usage of fixed_voltage_ops and fixed_voltage_clkenabled_ops is to assign their address the ops field in the regulator_desc struct, which is a const pointer. Make them const to allow the compiler to put them in read-only memory. make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-3-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-14regulator: dummy: Constify dummy_initdata and dummy_opsRikard Falkeborn
The only usage of dummy_initdata is to assign its address to the init_data field of the regulator_config struct and the only usage dummy_ops is to assign its address to the ops field in the regulator_desc struct, both which are const pointers. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200913084114.8851-2-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-11Merge tag 'regulator-fix-v5.9-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "The biggest set of fixes here is those from Michał Mirosław fixing some locking issues with coupled regulators that are triggered in cases where a coupled regulator is used by a device involved in fs_reclaim like eMMC storage. These are relatively serious for the affected systems, though the circumstances where they trigger are very rare" * tag 'regulator-fix-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: pwm: Fix machine constraints application regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive() regulator: remove superfluous lock in regulator_resolve_coupling() regulator: cleanup regulator_ena_gpio_free() regulator: plug of_node leak in regulator_register()'s error path regulator: push allocation in set_consumer_device_supply() out of lock regulator: push allocations in create_regulator() outside of lock regulator: push allocation in regulator_ena_gpio_request() out of lock regulator: push allocation in regulator_init_coupling() outside of lock regulator: fix spelling mistake "Cant" -> "Can't" regulator: cros-ec-regulator: Add NULL test for devm_kmemdup call
2020-09-10regulator: bd718x7: Make some variable staticYueHaibing
Fix sparse warnings: drivers/regulator/bd718x7-regulator.c:576:28: warning: symbol 'bd71847_swcontrol_ops' was not declared. Should it be static? drivers/regulator/bd718x7-regulator.c:585:28: warning: symbol 'bd71847_hwcontrol_ops' was not declared. Should it be static? drivers/regulator/bd718x7-regulator.c:902:28: warning: symbol 'bd71837_swcontrol_ops' was not declared. Should it be static? drivers/regulator/bd718x7-regulator.c:913:28: warning: symbol 'bd71837_hwcontrol_ops' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-By: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200910034240.37268-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-07Merge series "regulator: unexport regulator_lock/unlock()" from Michał ↵Mark Brown
Mirosław <mirq-linux@rere.qmqm.pl>: This removes regulator_lock/unlock() calls around regulator_notifier_call_chain() as they are redundant - drivers already have to guarantee regulator_dev's existence during the call. This should make reasoing about the lock easier, as this was the only use outside regulator core code. The only client that needed recursive locking from the notifier chain was drivers/usb/host/ohci-da8xx.c, which responds to over-current notification by calling regulator_disable(). Michał Mirosław (3): regulator: don't require mutex for regulator_notifier_call_chain() regulator: remove locking around regulator_notifier_call_chain() regulator: unexport regulator_lock/unlock() drivers/regulator/core.c | 11 +++-------- drivers/regulator/da9055-regulator.c | 2 -- drivers/regulator/da9062-regulator.c | 2 -- drivers/regulator/da9063-regulator.c | 2 -- drivers/regulator/da9210-regulator.c | 4 ---- drivers/regulator/da9211-regulator.c | 4 ---- drivers/regulator/lp8755.c | 6 ------ drivers/regulator/ltc3589.c | 10 ++-------- drivers/regulator/ltc3676.c | 10 ++-------- drivers/regulator/pv88060-regulator.c | 10 ++-------- drivers/regulator/pv88080-regulator.c | 10 ++-------- drivers/regulator/pv88090-regulator.c | 10 ++-------- drivers/regulator/slg51000-regulator.c | 4 ---- drivers/regulator/stpmic1_regulator.c | 4 ---- drivers/regulator/wm831x-dcdc.c | 4 ---- drivers/regulator/wm831x-isink.c | 2 -- drivers/regulator/wm831x-ldo.c | 2 -- drivers/regulator/wm8350-regulator.c | 2 -- include/linux/regulator/driver.h | 3 --- 19 files changed, 13 insertions(+), 89 deletions(-) -- 2.20.1
2020-09-07regulator: lochnagar: Add additional VDDCORE rangeCharles Keepax
In the case of an unrecognised mini-card the Lochnagar will not initialise the VDDCORE voltage register leading to a value outside of the current range. Add an additional range to cover these values, initially this wasn't done since they are duplicates of the existing minimum value. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200904122506.28017-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-04-18 18:20:44 +0000