Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201210212748.5849-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add proper modalias structures to let this driver load automatically if
compiled as module, because max14577 MFD driver creates MFD cells with
such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201210112139.5370-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch fixes a couple of bugs in the DA9121 driver.
One in an uninialised string I forgot to remove when changing to of_parse_cb()
The other is an index for an optional DT property which overflows
Adam Ward (2):
regulator: da9121: Remove uninitialised string variable
regulator: da9121: Fix index used for DT property
drivers/regulator/da9121-regulator.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
1.9.1
There is a missing "return ret;" on this error path so we call
"da9121_check_device_type(i2c, chip);" which will end up dereferencing
"chip->regmap" and lead to an Oops.
Fixes: c860476b9e ("regulator: da9121: Add device variant regmaps")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/X85soGKnWAjPUA7a@mwanda
Signed-off-by: Mark Brown <broonie@kernel.org>
When I use the axp20x chip to power my SDIO device on the 5.4 kernel,
the output voltage of DLDO2 is wrong. After comparing the register
manual and source code of the chip, I found that the mask bit of the
driver register of the port was wrong. I fixed this error by modifying
the mask register of the source code. This error seems to be a copy
error of the macro when writing the code. Now the voltage output of
the DLDO2 port of axp20x is correct. My development environment is
Allwinner A40I of arm architecture, and the kernel version is 5.4.
Signed-off-by: DingHua Ma <dinghua.ma.sz@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Cc: <stable@vger.kernel.org>
Fixes: db4a555f7c ("regulator: axp20x: use defines for masks")
Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support from RPMH regulators found in PM8350 and PM8350c PMICs
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20201203071244.2652297-2-vkoul@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
When CONFIG_GPIOLIB is disabled, the declarations from linux/gpio/consumer.h
are not visible:
drivers/regulator/da9121-regulator.c:371:14: error: implicit declaration of function 'fwnode_gpiod_get_index' [-Werror,-Wimplicit-function-declaration]
ena_gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), "enable", 0,
^
drivers/regulator/da9121-regulator.c:372:7: error: use of undeclared identifier 'GPIOD_OUT_HIGH'
GPIOD_OUT_HIGH |
^
drivers/regulator/da9121-regulator.c:373:7: error: use of undeclared identifier 'GPIOD_FLAGS_BIT_NONEXCLUSIVE'
GPIOD_FLAGS_BIT_NONEXCLUSIVE,
Include this explicitly to help compile testing.
Fixes: 46c413d5bb ("regulator: da9121: Add support for device variants via devicetree")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201204165229.3754763-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following sparse warnings:
drivers/regulator/da9121-regulator.c:55:21: warning: symbol 'da9121_10A_2phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:63:21: warning: symbol 'da9121_6A_2phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:71:21: warning: symbol 'da9121_5A_1phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:79:21: warning: symbol 'da9121_3A_1phase_current' was not declared. Should it be static?
drivers/regulator/da9121-regulator.c:151:32: warning: symbol 'status_event_handling' was not declared. Should it be static?
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Acked-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/1606994795-36182-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds interrupt handler for variants, and notifications for events; over
temperature/voltage/current. Because the IRQs are triggered by persisting
status, they must be masked and the status polled until clear, before the
IRQ can be enabled again.
Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com>
Link: https://lore.kernel.org/r/fe21796bbcbadff84a472a4cc581ae8fafc7f8f5.1606755367.git.Adam.Ward.opensource@diasemi.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add NXP PF8100/PF8121A/PF8200 regulator driver.
PF8100/PF8121A/PF8200 is PMIC designed for highperformance
consumer applications. It features seven high efficiency buck,
four linear and one vsnvs regulators.
Tested in Engicam i.Core MX8M Mini SOM platform boards.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Link: https://lore.kernel.org/r/20201130112329.104614-2-jagan@amarulasolutions.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Selectors lower than linear_min_sel should not be considered invalid.
Thus return zero in case _regulator_list_voltage(),
regulator_list_hardware_vsel() or regulator_list_voltage_table()
receives such selectors as argument.
Fixes: bdcd117757 ("regulator: core: validate selector against linear_min_sel")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1606325147-606-1-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The kernel test robot reported the following build error:
All errors (new ones prefixed by >>):
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_vrm_get_voltage_sel':
qcom-rpmh-regulator.c:(.text+0x270): undefined reference to `rpmh_write'
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_send_request':
qcom-rpmh-regulator.c:(.text+0x2f2): undefined reference to `rpmh_write'
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_vrm_get_voltage_sel':
>> qcom-rpmh-regulator.c:(.text+0x274): undefined reference to `rpmh_write_async'
xtensa-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_send_request':
qcom-rpmh-regulator.c:(.text+0x2fc): undefined reference to `rpmh_write_async'
Which is due to REGULATOR_QCOM_RPMH depending on
QCOM_RPMH || COMPILE_TEST. The problem is that QOM_RPMH can now
be a module, which in that case requires REGULATOR_QCOM_RPMH=m
to build.
However, if COMPILE_TEST is enabled, REGULATOR_QCOM_RPMH can be
set to =y while QCOM_RPMH=m which will cause build failures.
The fix here is to add (QCOM_RPMH=n && COMPILE_TEST) to the
dependency.
Feedback would be appreciated!
Cc: Todd Kjos <tkjos@google.com>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20201123222359.103822-1-john.stultz@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a simple regulator based on SCMI Voltage Domain Protocol.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
----
v6 --> v7
- add proper blank lines between semantic blocks
- fix return value on error path of scmi_reg_is_enabled()
- use generic Failure message on err path of info_get()
- fix comment containing apostrophe
v3 --> v4
- using of_match_full_name core regulator flag
- avoid coccinelle falde complaints about pointer-sized allocations
v2 --> v3
- remove multiple linear mappings support
- removed duplicated voltage name printout
- added a few comments
- simplified return path in scmi_reg_set_voltage_sel()
v1 --> v2
- removed duplicate regulator naming
- removed redundant .get/set_voltage ops: only _sel variants implemented
- removed condexpr on fail path to increase readability
v0 --> v1
- fixed init_data constraint parsing
- fixes for v5.8 (linear_range.h)
- fixed commit message content and subject line format
- factored out SCMI core specific changes to distinct patch
- reworked Kconfig and Makefile to keep proper alphabetic order
- fixed SPDX comment style
- removed unneeded inline functions
- reworked conditionals for legibility
- fixed some return paths to properly report SCMI original errors codes
- added some more descriptive error messages when fw returns invalid ranges
- removed unneeded explicit devm_regulator_unregister from .remove()
Link: https://lore.kernel.org/r/20201123202336.46701-4-cristian.marussi@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
this series introduces the support for the new SCMI Voltage Domain Protocol
defined by the upcoming SCMIv3.0 specification, whose BETA release is
available at [1].
Afterwards, a new generic SCMI Regulator driver is developed on top of the
new SCMI VD Protocol.
In V4 Patch 3/5 introduced a needed fix in Regulator framework to cope with
generic named nodes.
The series is currently based on for-next/scmi [2] on top of:
commit b141fca08207 ("firmware: arm_scmi: Fix missing destroy_workqueue()")
Any feedback welcome,
Thanks,
Cristian
---
v5 --> v6
- reordered dt bindings patch
- removed single field struct
- reviewed args to scmi_init_voltage_levels()
- allocating scmi_voltage_info_array contiguously
v4 --> v5
- rebased
- VD Protocol
- removed inline
- moved segmented intervals defines
- fixed some macros complaints by checkpatch
v3 --> v4
- DT bindings
- using generic node names
- listing explicitly subset of supported regulators bindings
- SCMI Regulator
- using of_match_full_name core regulator flag
- avoid coccinelle false flag complaints
- VD Protocol
- avoid coccinelle false flag complaints
- avoiding fixed size typing
v2 --> v3
- DT bindings
- avoid awkard examples based on _cpu/_gpu regulators
- SCMI Regulator
- remove multiple linear mappings support
- removed duplicated voltage name printout
- added a few comments
- simplified return path in scmi_reg_set_voltage_sel()
- VD Protocol
- restrict segmented voltage domain descriptors to one triplet
- removed unneeded inline
- free allocated resources for invalid voltage domain
- added __must_check to info_get voltage operations
- added a few comments
- removed fixed size typing from struct voltage_info
v1 --> v2
- rebased on for-next/scmi v5.10
- DT bindings
- removed any reference to negative voltages
- SCMI Regulator
- removed duplicate regulator naming
- removed redundant .get/set_voltage ops: only _sel variants implemented
- removed condexpr on fail path to increase readability
- VD Protocol
- fix voltage levels query loop to reload full cmd description
between iterations as reported by Etienne Carriere
- ensure transport rx buffer is properly sized calli scmi_reset_rx_to_maxsz
between transfers
[1]:https://developer.arm.com/documentation/den0056/c/
[2]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi
Cristian Marussi (5):
firmware: arm_scmi: Add Voltage Domain Support
firmware: arm_scmi: add SCMI Voltage Domain devname
regulator: core: add of_match_full_name boolean flag
dt-bindings: arm: add support for SCMI Regulators
regulator: add SCMI driver
.../devicetree/bindings/arm/arm,scmi.txt | 43 ++
drivers/firmware/arm_scmi/Makefile | 2 +-
drivers/firmware/arm_scmi/common.h | 1 +
drivers/firmware/arm_scmi/driver.c | 3 +
drivers/firmware/arm_scmi/voltage.c | 380 ++++++++++++++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/of_regulator.c | 8 +-
drivers/regulator/scmi-regulator.c | 409 ++++++++++++++++++
include/linux/regulator/driver.h | 3 +
include/linux/scmi_protocol.h | 64 +++
11 files changed, 920 insertions(+), 3 deletions(-)
create mode 100644 drivers/firmware/arm_scmi/voltage.c
create mode 100644 drivers/regulator/scmi-regulator.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
During regulators registration, if .of_match and .regulators_node are
defined as non-null strings in struct regulator_desc the core searches the
DT subtree rooted at .regulators_node trying to match, at first, .of_match
against the 'regulator-compatible' property and, then, falling back to use
the name of the node itself to determine a good match.
Property 'regulator-compatible', though, is now deprecated and falling back
to match against the node name, works fine only as long as the involved
nodes are named in an unique way across the searched subtree; if that's not
the case, like when using <common-name>@<unit> style naming for properties
indexed via 'reg' property (as advised by the standard), the above matching
mechanism based on the simple common name will lead to multiple matches and
the only viable alternative would be to properly define the now deprecated
'regulator-compatible' as the node full name, i.e. <common-name>@<unit>.
In order to address this case without using such deprecated binding, define
a new boolean flag .of_match_full_name in struct regulator_desc to force
the core to match against the node full-name instead of the plain name.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20201119191051.46363-4-cristian.marussi@arm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
At the start of driver initialization, we do not know what bias
setting the bootloader has configured the system for and we only know
for certain the very first time we do a transition.
However, since the initial value of the comparison index is -EINVAL,
this negative value results in an array out of bound access on the
very first transition.
Since we don't know what the setting is, we just set the bias
configuration as there is nothing to compare against. This prevents
the array out of bound access.
NOTE: Even though we could use a more relaxed check of "< 0" the only
valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+.
Fixes: 40b1936efe ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver")
Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
This series adds support for ramp delay on mcp16502. It also adds
some cleanup on mcp16502.
Apart from that patches 1/6 fixes the selector validation in case
the regulator::desc::linear_min_sel is not zero.
Thank you,
Claudiu Beznea
Changes in v3:
- fix compilation error in patch 5/6
Reported-by: kernel test robot <lkp@intel.com>
Changes in v2:
- rebase on top of regulator/for-next
- checked 1/6 and 3/6 applies on top of regulator/for-5.10
Claudiu Beznea (6):
regulator: core: validate selector against linear_min_sel
regulator: core: do not continue if selector match
regulator: mcp16502: add linear_min_sel
regulator: mcp16502: adapt for get/set on other registers
regulator: mcp16502: add support for ramp delay
regulator: mcp16502: remove void documentation of struct mcp16502
drivers/regulator/core.c | 12 +++-
drivers/regulator/helpers.c | 3 +-
drivers/regulator/mcp16502.c | 135 ++++++++++++++++++++++++++++++++++++-------
3 files changed, 127 insertions(+), 23 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
There are regulators who's min selector is not zero. Selectors loops
(looping b/w zero and regulator::desc::n_voltages) might throw errors
because invalid selectors are used (lower than
regulator::desc::linear_min_sel). For this situations validate selectors
against regulator::desc::linear_min_sel.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-2-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MCP16502 have multiple registers for each regulator (as described
in enum mcp16502_reg). Adapt the code to be able to get/set all these
registers. This is necessary for the following commits.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/1605280870-32432-5-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
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: aea6cb9970 ("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>
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: aea6cb9970 ("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>
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: aea6cb9970 ("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>
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: 6f1cf5257a ("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>
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: 3cea11cd5e
--
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 =]
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>
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>
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>
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: aea6cb9970 ("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>
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/
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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
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: 45389c4752 ("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>
A single fix for incorrect specification of some of the register fields
on axp20x devices which would break voltage setting on affected systems.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9uTFQTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0OEZB/9tRSg6gHVdp2OwAbWPzJQcHYYP4stQ
H3mPcsDJRmpVnHhUQe3qlUvG4QZ7bDhnHFYS1G7LFgEBNVhCwKtpnseaQMJaCaa+
t9LLWNtzltuo75995bBtPYcSQI6U0yUYbu7U7n+4vibh/pjqY3eNg4lLrWtVL/OC
FwkCEql5+ZTTg3OcRHzKlYe1UlOB0kSHNCjySiVytPrC0UH32gFCs/LSZxDR8lbo
a9x8Vi8brbcmpASoCY0d+c0hM6PWB/chNwVHGnoWYJ+xoJMVLzC8TN/mkUgG++9i
wnwXfbUd0EbLKuLrZto0qdx14n2nLp2YpeLJhTbsJaQ5C+FQGvv7D2v5
=Uvnh
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v5.9-rc6' of 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
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: db4a555f7c ("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>
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>
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>
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: f4d51dffc6
--
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 =]
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>
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>
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>
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>
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>
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.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9baDITHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0NAOCACGwc1Rxsr9cMDY5vQS7AHzfPVRdoQJ
Z9KIOQT9ER0hFHRNh1/t1n/p4DcK+3ke0MH/R/VndijvePJgHyL01Bsjq92iDiIy
b80nDJwRwLWWdvKAPG5JklVK8pL/6LxaC9eL8zK93Hm4fGkNJzBi7jF2++jep/tB
2jRM4Vrq8B0dkh/jPQMscl4Z66purIiyKLJjy1QFjXXq0/jkjZizURy+aofS3uJD
0vebim9OI7z0H4g6cflJrHUAuDraNmGCfGAyUMH7AESJlUGNRk7BzNYT51tLVYqG
ithNZDh/AbWhGzntuUUKNlM4D8p26FNJmU51crh33kBH3va737dvc/BT
=3fwP
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v5.9-rc4' of 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
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>
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
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>
regulator_notifier_call_chain() doesn't need rdev lock and rdev's
existence is assumed in the code anyway. Remove the locks from drivers.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/42393f66dcc4d80dcd9797be45216b4035aa96cb.1597032945.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Since 3801b86aa4 ("regulator: Refactor supply implementation
to work as regular consumers") we no longer cascade notifications
and so notifier head's built-in rwsem is enough to protect the
notifier chain. Remove the requirement to fix one case where
rdev->mutex might be forced to be taken recursively.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/5a0da9017c69a4dbc3f9b50f44476fce80a73387.1597032945.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
The BD718(37/47/50) regulator enable states can be controlled
either by SW or by PMIC internal state machine. The bd718x7
driver has not supported leaving the regulators under HW state
machine control (except for cases where this is required to
avoid boot-up problems due to critical regulators being turned
OFF at reset when SNVS used as reset state).
On some systems this is undesirable as there now are setups where
mixture of SW and HW state machine controlled regulators is needed.
Specifically, some SoCs signal SUSPEND state change to PMIC via
STBY_REQ line. Now there are setups that expect certain regulators
then to be disabled (by PMIC state machine) while other regulators
should stay enabled (regardless of HW state => SW control required).
Add support for a new device-tree property
"rohm,no-regulator-enable-control" which can be used to leave
regulator(s) under HW state machine control.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/6ebba33dd08f2dcc9f1137bbff4d2dc905278a5a.1599029335.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the zero duty cycle doesn't correspond to any voltage in the voltage
table, the PWM regulator returns an -EINVAL from get_voltage_sel() which
results in the core erroring out with a "failed to get the current
voltage" and ending up not applying the machine constraints.
Instead, return -ENOTRECOVERABLE which makes the core set the voltage
since it's at an unknown value.
For example, with this device tree:
fooregulator {
compatible = "pwm-regulator";
pwms = <&foopwm 0 100000>;
regulator-min-microvolt = <2250000>;
regulator-max-microvolt = <2250000>;
regulator-name = "fooregulator";
regulator-always-on;
regulator-boot-on;
voltage-table = <2250000 30>;
};
Before this patch:
fooregulator: failed to get the current voltage(-22)
After this patch:
fooregulator: Setting 2250000-2250000uV
fooregulator: 2250 mV
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20200902130952.24880-1-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage 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/20200829221104.20870-9-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps65912_ops_dcdc and tps65912_ops_ldo 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/20200829221104.20870-8-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of these are 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/20200829221104.20870-7-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usages of these are 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/20200829221104.20870-6-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of reg_ops and switch_ops is to assign their addresses 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/20200829221104.20870-5-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps62360_dcdc_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/20200829221104.20870-4-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps6105x_regulator_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/20200829221104.20870-3-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only usage of tps51632_dcdc_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/20200829221104.20870-2-rikard.falkeborn@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The recent commit 7d8196641e ("regulator: Remove pointer table
overallocation") changed the size of coupled_rdevs and now KASAN is able
to detect slab-out-of-bounds problem in regulator_unlock_recursive(),
which is a legit problem caused by a typo in the code. The recursive
unlock function uses n_coupled value of a parent regulator for unlocking
supply regulator, while supply's n_coupled should be used. In practice
problem may only affect platforms that use coupled regulators.
Cc: stable@vger.kernel.org # 5.0+
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200831204335.19489-1-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As Rob suggested, use the "mps,switch-frequency-hz" instead of the
"mps,switch-frequency" for switch frequency. Fortunately, the switch
frequency support isn't released, so we can modify it now without
any concern.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200824102402.4047fa5f@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The following build warning is seen after commit 8bdaa43808 ("regulator:
dbx500: no need to check return value of debugfs_create functions"):
drivers/regulator/dbx500-prcmu.c:144:1: warning: label 'exit_no_debugfs' defined but not used [-Wunused-label]
Remove the unused label and its associated error message.
Fixes: 8bdaa43808 ("regulator: dbx500: no need to check return value of debugfs_create functions")
Reported-by: Olof's autobuilder <build@lixom.net>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20200821144823.13404-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/tps65023-regulator.c:319:34: warning: ‘tps65023_of_match’ defined but not used [-Wunused-const-variable=]
319 | static const struct of_device_id tps65023_of_match[] = {
| ^~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821112009.58ee8511@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/qcom-rpmh-regulator.c:970:34: warning: ‘rpmh_regulator_match_table’ defined but not used [-Wunused-const-variable=]
970 | static const struct of_device_id rpmh_regulator_match_table[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111913.1096f7cc@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/sy8106a-regulator.c:126:34: warning: ‘sy8106a_i2c_of_match’ defined but not used [-Wunused-const-variable=]
126 | static const struct of_device_id sy8106a_i2c_of_match[] = {
| ^~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111820.5c6ddb04@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/stm32-pwr.c:169:34: warning: ‘stm32_pwr_of_match’ defined but not used [-Wunused-const-variable=]
169 | static const struct of_device_id stm32_pwr_of_match[] = {
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111726.38e0e746@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/pwm-regulator.c:393:34: warning: ‘pwm_of_match’ defined but not used [-Wunused-const-variable=]
393 | static const struct of_device_id pwm_of_match[] = {
| ^~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111658.59a7218b@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/max77826-regulator.c:277:34: warning: ‘max77826_of_match’ defined but not used [-Wunused-const-variable=]
277 | static const struct of_device_id max77826_of_match[] = {
| ^~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111631.4e799c86@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/max1586.c:204:34: warning: ‘max1586_of_match’ defined but not used [-Wunused-const-variable=]
204 | static const struct of_device_id max1586_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111601.26243417@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3676.c:371:34: warning: ‘ltc3676_of_match’ defined but not used [-Wunused-const-variable=]
371 | static const struct of_device_id ltc3676_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111517.59d7b8c8@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/ltc3589.c:460:34: warning: ‘ltc3589_of_match’ defined but not used [-Wunused-const-variable=]
460 | static const struct of_device_id ltc3589_of_match[] = {
| ^~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111449.7cf580f2@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warnings when CONFIG_OF=n:
drivers/regulator/fixed.c:48:36: warning: ‘fixed_clkenable_data’ defined but not used [-Wunused-const-variable=]
48 | static const struct fixed_dev_type fixed_clkenable_data = {
| ^~~~~~~~~~~~~~~~~~~~
drivers/regulator/fixed.c:44:36: warning: ‘fixed_voltage_data’ defined but not used [-Wunused-const-variable=]
44 | static const struct fixed_dev_type fixed_voltage_data = {
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111403.3e8b58a3@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/fan53555.c:439:34: warning: ‘fan53555_dt_ids’ defined but not used [-Wunused-const-variable=]
439 | static const struct of_device_id fan53555_dt_ids[] = {
| ^~~~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111324.430fe1da@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/da9210-regulator.c:128:34: warning: ‘da9210_dt_ids’ defined but not used [-Wunused-const-variable=]
128 | static const struct of_device_id da9210_dt_ids[] = {
| ^~~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200821111235.14473a88@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix below warning when CONFIG_OF=n:
drivers/regulator/88pg86x.c:87:34: warning: ‘pg86x_dt_ids’ defined but not used [-Wunused-const-variable=]
87 | static const struct of_device_id pg86x_dt_ids [] = {
| ^~~~~~~~~~~~
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200821111210.0a0bed94@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org
Link: https://lore.kernel.org/r/20200818133701.462958-1-gregkh@linuxfoundation.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This allows the regulator to be found by devm_regulator_get().
Fixes: 4fe66d5a62 ("regulator: Add support for QCOM PMIC VBUS booster")
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20200818162508.5246-1-jonathan@marek.ca
Signed-off-by: Mark Brown <broonie@kernel.org>
Jisheng Zhang <Jisheng.Zhang@synaptics.com>:
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
This is to improve the mp886x regulator driver support.
patch1 implments .set_ramp_delay
patch2 and patch3 support the switch freq setting
patch4 converts dt binding to json-schema
Since v2:
- put any schema conversions at the end of the series as Mark
suggested.
Jisheng Zhang (4):
regulator: mp886x: implement set_ramp_delay
dt-bindings: regulator: mp886x: support mps,switch-frequency
regulator: mp886x: support setting switch freq
dt-bindings: regulator: Convert mp886x to json-schema
.../devicetree/bindings/regulator/mp886x.txt | 27 -----
.../bindings/regulator/mps,mp886x.yaml | 58 ++++++++++
drivers/regulator/mp886x.c | 109 +++++++++++++++++-
3 files changed, 164 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/regulator/mp886x.txt
create mode 100644 Documentation/devicetree/bindings/regulator/mps,mp886x.yaml
--
2.28.0.rc1
For systems that have eg. eMMC storage using voltage regulator, memory
reclaim path might call back into regulator subsystem. This means we
have to make sure no allocations happen with a regulator or regulator
list locked.
After this series I see no more lockdep complaints on my test system,
but please review and test further.
First four patches move allocations out of locked regions, next three
came as a drive-by cleanups.
---
v2: fix bug in patch #4 spotted by kernel test robot
reworded commit #7 description
Michał Mirosław (7):
regulator: push allocation in regulator_init_coupling() outside of
lock
regulator: push allocation in regulator_ena_gpio_request() out of lock
regulator: push allocations in create_regulator() outside of lock
regulator: push allocation in set_consumer_device_supply() out of lock
regulator: plug of_node leak in regulator_register()'s error path
regulator: cleanup regulator_ena_gpio_free()
regulator: remove superfluous lock in regulator_resolve_coupling()
drivers/regulator/core.c | 164 +++++++++++++++++++++------------------
1 file changed, 87 insertions(+), 77 deletions(-)
--
2.20.1
By checking data->pin_ctrl_enable / data->pin_ctrl_hpm flags first, then
use switch-case to improve readability.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200801054820.134859-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This regulator/backlight driver handles the ATTINY88 present on the
RPi 7" touchscreen panel and exposes the power/backlight interfaces.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Mark Brown <broonie@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
To: dri-devel@lists.freedesktop.org
Link: https://lore.kernel.org/r/20200809105938.6388-2-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
I see it takes about 5us per regulator to grab the lock, check that this
regulator isn't going to do anything for suspend, and then release the
lock. When that is combined with PMICs that have dozens of regulators we
get into a state where we spend a few miliseconds doing a bunch of
locking operations synchronously to figure out that there's nothing to
do. Let's reorganize the code here a bit so that we don't grab the lock
until we're actually going to do something so that suspend is a little
faster.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200804070837.1084024-1-swboyd@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fixing W=1 build warning when no support for device tree is there.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200810095753.59ce9f75@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Add regmap_cache to reduce wakeups events of interrupt if regulator is
accessed frequently. This results in saving more power.
Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/20200812133101.2513317-1-hsinyi@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Adds support for the RT4801 DSV. It has two regulators (DSVP/DSVN) with
an I2C interface. DSVP/DSVN can provide the display panel module for the
positive/negative voltage range from (+/-)4V to (+/-)6V.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1597461262-25878-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The code modifies rdev, but locks c_rdev instead. Remove the lock
as this is held together by regulator_list_mutex taken in the caller.
Fixes: f9503385b1 ("regulator: core: Mutually resolve regulators coupling")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Since only regulator_ena_gpio_request() allocates rdev->ena_pin, and it
guarantees that same gpiod gets same pin structure, it is enough to
compare just the pointers. Also we know there can be only one matching
entry on the list. Rework the code take advantage of the facts.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/3ff002c7aa3bd774491af4291a9df23541fcf892.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
By calling device_initialize() earlier and noting that kfree(NULL) is
ok, we can save a bit of code in error handling and plug of_node leak.
Fixed commit already did part of the work.
Fixes: 9177514ce3 ("regulator: fix memory leak on error path of regulator_register()")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Move all allocations outside of the regulator_lock()ed section.
======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #535 Not tainted
------------------------------------------------------
f2fs_discard-179:7/702 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0
but task is already holding lock:
cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
[...]
-> #3 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc_track_caller+0x54/0x218
kstrdup+0x40/0x5c
create_regulator+0xf4/0x368
regulator_resolve_supply+0x1a0/0x200
regulator_register+0x9c8/0x163c
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock
[...]
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.
WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
kmem_cache_alloc_trace+0x40/0x1e8
regulator_register+0x384/0x1630
devm_regulator_register+0x50/0x84
reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(regulator_list_mutex);
*** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
#1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]
Fixes: 541d052d72 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Allocating memory with regulator_list_mutex held makes lockdep unhappy
when memory pressure makes the system do fs_reclaim on eg. eMMC using
a regulator. Push the lock inside regulator_init_coupling() after the
allocation.
======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154
but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:
fs_reclaim_acquire.part.11+0x40/0x50
fs_reclaim_acquire+0x24/0x28
__kmalloc+0x54/0x218
regulator_register+0x860/0x1584
dummy_regulator_probe+0x60/0xa8
[...]
other info that might help us debug this:
Chain exists of:
&sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(regulator_list_mutex);
lock(fs_reclaim);
lock(&sbi->write_io[i][j].io_rwsem);
*** DEADLOCK ***
1 lock held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]
Fixes: d8ca7d184b ("regulator: core: Introduce API for regulators coupling customization")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Both MP8867 and MP8869 support different switch frequency.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200729131023.77cc1dd2@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
Implement the .set_ramp_delay for MP8867 and MP8869. MP8867 and MP8869
could share the implementation, the only difference is the slew_rates
array.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20200729130913.3ac38b32@xhacker
Signed-off-by: Mark Brown <broonie@kernel.org>
Zheng Yongjun