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>
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>
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>
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>
