Thanks to the removal of the unused TPS80021 driver the regulator
updates for this cycle actually have a negative diffstat. Otherwise
it's been quite a quiet release, lots of fixes and small improvements
with the biggest individual changes being several conversions of DT
bindings to YAML format.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmF//M0ACgkQJNaLcl1U
h9ByVQf/QapSey1s8ifh7Or3oiG7Ak6BdPYxiPIzhZIqjz4gXV8ySn8EedbH7moW
NcKpqokZ4qPD32fcET2WFQLb9tA8BNEQS1VwRKG+uhzPi3xBnIVj0gt8lNOAW57g
cUWeJhIbafaym33zB0xdDAukLHqjnx24C33Fz8QWaaQv/xRhaCrbzhala4WfXXyP
ucyOqSNnHZ+KX0tQsIG05b9jqca+VrNAyefY5jum2l2r2LFfGjQDv6g0HJEKfcF3
PSu+1RBFsYA3sPvzqzdtcuEs7hqalXVNGBfogCzNQ1HhK9z48R4J9lHtswDDk4EA
9aLYiid02UYRpRpT34z2TexpufW9kQ==
=5lYk
-----END PGP SIGNATURE-----
Merge tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator updates from Mark Brown:
"Thanks to the removal of the unused TPS80021 driver the regulator
updates for this cycle actually have a negative diffstat.
Otherwise it's been quite a quiet release, lots of fixes and small
improvements with the biggest individual changes being several
conversions of DT bindings to YAML format"
* tag 'regulator-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (34 commits)
regulator: Don't error out fixed regulator in regulator_sync_voltage()
regulator: tps80031: Remove driver
regulator: Fix SY7636A breakage
regulator: uniphier: Add binding for NX1 SoC
regulator: uniphier: Add USB-VBUS compatible string for NX1 SoC
regulator: qcom,rpmh: Add compatible for PM6350
regulator: qcom-rpmh: Add PM6350 regulators
regulator: sy7636a: Remove requirement on sy7636a mfd
regulator: tps62360: replacing legacy gpio interface for gpiod
regulator: lp872x: Remove lp872x_dvs_state
regulator: lp872x: replacing legacy gpio interface for gpiod
regulator: dt-bindings: samsung,s5m8767: convert to dtschema
regulator: dt-bindings: samsung,s2mpa01: convert to dtschema
regulator: dt-bindings: samsung,s2m: convert to dtschema
dt-bindings: clock: samsung,s2mps11: convert to dtschema
regulator: dt-bindings: samsung,s5m8767: correct s5m8767,pmic-buck-default-dvs-idx property
regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled
regulator: dt-bindings: maxim,max8973: convert to dtschema
regulator: dt-bindings: maxim,max8997: convert to dtschema
regulator: dt-bindings: maxim,max8952: convert to dtschema
...
- Move futex code into kernel/futex/ and split up the kitchen sink into
seperate files to make integration of sys_futex_waitv() simpler.
- Add a new sys_futex_waitv() syscall which allows to wait on multiple
futexes. The main use case is emulating Windows' WaitForMultipleObjects
which allows Wine to improve the performance of Windows Games. Also
native Linux games can benefit from this interface as this is a common
wait pattern for this kind of applications.
- Add context to ww_mutex_trylock() to provide a path for i915 to rework
their eviction code step by step without making lockdep upset until the
final steps of rework are completed. It's also useful for regulator and
TTM to avoid dropping locks in the non contended path.
- Lockdep and might_sleep() cleanups and improvements
- A few improvements for the RT substitutions.
- The usual small improvements and cleanups.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmF/FTITHHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoVNZD/9vIm3Bu1Coz8tbNXz58AiCYq9Y/vp5
mzFgSzz+VJTkW5Vh8jo5Uel4rCKZyt+rL276EoaRPzYl8KFtWDbpK3qd3PrXKqTX
At49JO4ttAMJUHIBQ6vblEkykmfEd9YPU1uSWk5roJ+s7Jmr5VWnu0FEWHP00As5
tWOca/TM0ei9kof26V2fl5aecTGII4i4Zsvy+LPsXtI+TnmP0gSBcGAS/5UnZTtJ
vQRWTR3ojoYvh5iTmNqbaURYoQLe2j8yscn1DSW1CABWVmP12eDWs+N7jRP4b5S9
73xOv5P7vpva41wxrK2ir5iNkpsLE97VL2JOHTW8nm7orblfiuxHLTCkTjEdd2pO
h8blI2IBizEB3JYn2BMkOAaZQOSjN8hd6Ye/b2B4AMEGWeXEoEv6eVy/orYKCluQ
XDqGn47Vce/SYmo5vfTB8VMt6nANx8PKvOP3IvjHInYEQBgiT6QrlUw3RRkXBp5s
clQkjYYwjAMVIXowcCrdhoKjMROzi6STShVwHwGL8MaZXqr8Vl6BUO9ckU0pY+4C
F000Hzwxi8lGEQ9k+P+BnYOEzH5osCty8lloKiQ/7ciX6T+CZHGJPGK/iY4YL8P5
C3CJWMsHCqST7DodNFJmdfZt99UfIMmEhshMDduU9AAH0tHCn8vOu0U6WvCtpyBp
BvHj68zteAtlYg==
=RZ4x
-----END PGP SIGNATURE-----
Merge tag 'locking-core-2021-10-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking updates from Thomas Gleixner:
- Move futex code into kernel/futex/ and split up the kitchen sink into
seperate files to make integration of sys_futex_waitv() simpler.
- Add a new sys_futex_waitv() syscall which allows to wait on multiple
futexes.
The main use case is emulating Windows' WaitForMultipleObjects which
allows Wine to improve the performance of Windows Games. Also native
Linux games can benefit from this interface as this is a common wait
pattern for this kind of applications.
- Add context to ww_mutex_trylock() to provide a path for i915 to
rework their eviction code step by step without making lockdep upset
until the final steps of rework are completed. It's also useful for
regulator and TTM to avoid dropping locks in the non contended path.
- Lockdep and might_sleep() cleanups and improvements
- A few improvements for the RT substitutions.
- The usual small improvements and cleanups.
* tag 'locking-core-2021-10-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (44 commits)
locking: Remove spin_lock_flags() etc
locking/rwsem: Fix comments about reader optimistic lock stealing conditions
locking: Remove rcu_read_{,un}lock() for preempt_{dis,en}able()
locking/rwsem: Disable preemption for spinning region
docs: futex: Fix kernel-doc references
futex: Fix PREEMPT_RT build
futex2: Documentation: Document sys_futex_waitv() uAPI
selftests: futex: Test sys_futex_waitv() wouldblock
selftests: futex: Test sys_futex_waitv() timeout
selftests: futex: Add sys_futex_waitv() test
futex,arm: Wire up sys_futex_waitv()
futex,x86: Wire up sys_futex_waitv()
futex: Implement sys_futex_waitv()
futex: Simplify double_lock_hb()
futex: Split out wait/wake
futex: Split out requeue
futex: Rename mark_wake_futex()
futex: Rename: match_futex()
futex: Rename: hb_waiter_{inc,dec,pending}()
futex: Split out PI futex
...
TPS80031 driver was upstreamed back in 2013 and never got a user. I noticed
that driver is abandoned while was about to write a patch to switch it to a
new power-off API (that I'm working on). Driver requires platform data that
nobody provides. Instead of changing the dead code, let's remove it.
Dmitry Osipenko (3):
rtc: tps80031: Remove driver
regulator: tps80031: Remove driver
mfd: tps80031: Remove driver
drivers/mfd/Kconfig | 14 -
drivers/mfd/Makefile | 1 -
drivers/mfd/tps80031.c | 526 -----------------
drivers/regulator/Kconfig | 9 -
drivers/regulator/Makefile | 1 -
drivers/regulator/tps80031-regulator.c | 753 -------------------------
drivers/rtc/Kconfig | 8 -
drivers/rtc/Makefile | 1 -
drivers/rtc/rtc-tps80031.c | 324 -----------
include/linux/mfd/tps80031.h | 637 ---------------------
10 files changed, 2274 deletions(-)
delete mode 100644 drivers/mfd/tps80031.c
delete mode 100644 drivers/regulator/tps80031-regulator.c
delete mode 100644 drivers/rtc/rtc-tps80031.c
delete mode 100644 include/linux/mfd/tps80031.h
--
2.32.0
Fixed regulator can't change voltage and regulator_sync_voltage()
returns -EINVAL in this case. Make regulator_sync_voltage() to succeed
for regulators that are incapable to change voltage.
On NVIDIA Tegra power management driver needs to sync voltage and we have
one device (Trimslice) that uses fixed regulator which is getting synced.
The syncing error isn't treated as fatal, but produces a noisy error
message. This patch silences that error.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20211021183308.27786-1-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The MFD for SY7636A still isn't merged so we need a dependency even if
it ends up not having a real driver due to the header file.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mark Brown <broonie@kernel.org>
This series includes the patches to add basic support for new UniPhier NX1
SoC. NX1 SoC also has the same kinds of controls as the other UniPhier
SoCs.
Kunihiko Hayashi (2):
dt-bindings: regulator: uniphier: Add binding for NX1 SoC
regulator: uniphier: Add USB-VBUS compatible string for NX1 SoC
.../devicetree/bindings/regulator/socionext,uniphier-regulator.yaml | 1 +
drivers/regulator/uniphier-regulator.c | 4 ++++
2 files changed, 5 insertions(+)
--
2.7.4
Add the configuration for pm6350 regulators. The supplies are not known
so leave them out for now.
Additionally leave out configuration of smps3 - smps5 and ldo17 as these
are not configured in the downstream kernel and the type of them is not
known.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lore.kernel.org/r/20211007212444.328034-4-luca@z3ntu.xyz
Signed-off-by: Mark Brown <broonie@kernel.org>
Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface.
Signed-off-by: Maíra Canal <maira.canal@usp.br>
Link: https://lore.kernel.org/r/YWxmL2baF5AdzyHv@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
After this driver was converted to gpiod, clang started warning:
vers/regulator/lp872x.c:689:57: error: implicit conversion from
enumeration type 'enum lp872x_dvs_state' to different enumeration type
'enum gpiod_flags' [-Werror,-Wenum-conversion]
dvs->gpio = devm_gpiod_get_optional(lp->dev, "ti,dvs", pinstate);
~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~
1 error generated.
lp872x_dvs_state was updated to have values from gpiod_flags but this is
not enough to avoid an implicit conversion warning from either GCC or
clang (although GCC enables this warning under -Wextra instead of -Wall
like clang so it is not seen under normal builds).
Eliminate lp872x_dvs_state in favor of using gpiod_flags everywhere so
that there is no more warning about an implicit conversion.
Fixes: 72bf80cf09 ("regulator: lp872x: replacing legacy gpio interface for gpiod")
Link: https://github.com/ClangBuiltLinux/linux/issues/1481
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211019004335.193492-1-nathan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Tagged to allow further bindings to rely on these.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmFgkpYTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0OPnB/9M7HLzuTV7mkG0buI1vIPDjuSCWsr/
TZ9IuZIy0OmtdcXq9F0VyRq6wy6bVMXVSlrlFQLnrPLFW1/MIqeyPmLJyqwKVYh/
lyrAaHfeKck2S2ususisudBr/Qkg0ZrEX2f1eLC03xBnBEOy3Nl71s/HxbO9n4yt
ZAUk/1/UlmbhQKNlNgMtfXuXtLCGm3GRL30jb4nb/hGj/8Xb0ESmnRmkmZnVi/+H
DgHGHLDeK3Y5ntQx8IwbrPFimlvAGVgfU/ruf7Z6zmpuW2tKKcLE7ZAR8DG5ZRhw
W3WPq6YYUzAhyxgY0U2iO6wrL5rKvo65CbGOvpk9RsCYk2GxQS6BqHWX
=P4cy
-----END PGP SIGNATURE-----
Merge tag 'tags/s2m_s5m_dtschema' into tb-mfd-from-regulator-5.16
regulator/clock: Convert the s2m and s5m DT bindings to schema
Tagged to allow further bindings to rely on these.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Removing all linux/gpio.h and linux/of_gpio.h dependencies and replacing
them with the gpiod interface
Signed-off-by: Maíra Canal <maira.canal@usp.br>
Message-Id: <YWma2yTyuwS5XwhY@fedora>
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi All,
Changes since v2
================
1. Add Stephen's and Rob's tags.
2. Correct inb-supply description in patch 10/10.
Changes since v2
================
1. Add Rob's tags.
2. Remove "regulator-name" from properties (all regulator dtschema).
3. Move "unevaluatedProperties" higher to make code easier to read (all regulator dtschema).
4. Add ref-type to op-mode property (patch 6: s5m8767 regulators).
Changes since v1
================
1. Drop DTS patches - applied.
2. Fully remove bindings/regulator/samsung,s5m8767.txt .
3. Minor subject reformatting and few typos in text.
Intro
=====
This patchset converts all devicetree bindings of Samsung S2M and S5M
PMIC devices from txt to dtschema.
It includes also two fixes because later conversion depends on it
(contextually).
Merging/dependencies
====================
1. Regulator related binding changes depend on first two commits (the
fixes), because of context.
2. The mfd bindings depend on clock and regulator bindings.
The fixes and bindings changes (patches 1-10) should go via the same
tree. For example regulator or mfd tree.
Another alternative is that regulator patches (1-2, 4-6) go via Mark who
later gives MFD a stable branch/tag to pull. Then the clock and MFD
bindings would go on top via MFD tree. Or any other setup you would like
to have.
Overview of devices
===================
Essentially all Samsung S2M and S5M PMICs are very similar devices. They
provide the same functionality: regulators, RTC, 2 or 3 clocks and main
power management (e.g. power cut to SoC).
The differences are mostly in registers layout and number of regulators.
The drivers are built around one common part, mfd/sec-core.c, and share
some drivers between devices:
1. MFD sec-core for all devices,
1. one clock driver for most of devices,
2. one RTC driver for all devices,
3. three regulator drivers.
The regulator drivers were implementing slightly different features,
therefore one regulator binding for all devices does not make much
sense. However the clock device binding can be shared.
The final dtschema bindings try to implement this - share only the clock
bindings.
Best regards,
Krzysztof
Krzysztof Kozlowski (10):
regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS
is disabled
regulator: dt-bindings: samsung,s5m8767: correct
s5m8767,pmic-buck-default-dvs-idx property
dt-bindings: clock: samsung,s2mps11: convert to dtschema
regulator: dt-bindings: samsung,s2m: convert to dtschema
regulator: dt-bindings: samsung,s2mpa01: convert to dtschema
regulator: dt-bindings: samsung,s5m8767: convert to dtschema
dt-bindings: mfd: samsung,s2mps11: convert to dtschema
dt-bindings: mfd: samsung,s2mpa01: convert to dtschema
dt-bindings: mfd: samsung,s5m8767: convert to dtschema
dt-bindings: mfd: samsung,s5m8767: document buck and LDO supplies
.../bindings/clock/samsung,s2mps11.txt | 49 ---
.../bindings/clock/samsung,s2mps11.yaml | 45 +++
.../bindings/mfd/samsung,s2mpa01.yaml | 91 ++++++
.../bindings/mfd/samsung,s2mps11.yaml | 267 +++++++++++++++
.../bindings/mfd/samsung,s5m8767.yaml | 307 ++++++++++++++++++
.../bindings/mfd/samsung,sec-core.txt | 86 -----
.../bindings/regulator/samsung,s2mpa01.txt | 79 -----
.../bindings/regulator/samsung,s2mpa01.yaml | 62 ++++
.../bindings/regulator/samsung,s2mps11.txt | 102 ------
.../bindings/regulator/samsung,s2mps11.yaml | 44 +++
.../bindings/regulator/samsung,s2mps13.yaml | 44 +++
.../bindings/regulator/samsung,s2mps14.yaml | 44 +++
.../bindings/regulator/samsung,s2mps15.yaml | 44 +++
.../bindings/regulator/samsung,s2mpu02.yaml | 44 +++
.../bindings/regulator/samsung,s5m8767.txt | 145 ---------
.../bindings/regulator/samsung,s5m8767.yaml | 74 +++++
MAINTAINERS | 9 +-
drivers/regulator/s5m8767.c | 21 +-
18 files changed, 1080 insertions(+), 477 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
create mode 100644 Documentation/devicetree/bindings/clock/samsung,s2mps11.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/samsung,s2mpa01.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml
delete mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
delete mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mpa01.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mps11.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mps13.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mps14.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mps15.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s2mpu02.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt
create mode 100644 Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml
--
2.30.2
The driver and its bindings, before commit 04f9f068a6 ("regulator:
s5m8767: Modify parsing method of the voltage table of buck2/3/4") were
requiring to provide at least one safe/default voltage for DVS registers
if DVS GPIO is not being enabled.
IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the
s5m8767,pmic-buck2-dvs-voltage should still be present and contain one
voltage.
This requirement was coming from driver behavior matching this condition
(none of DVS GPIO is enabled): it was always initializing the DVS
selector pins to 0 and keeping the DVS enable setting at reset value
(enabled). Therefore if none of DVS GPIO is enabled in devicetree,
driver was configuring the first DVS voltage for buck[234].
Mentioned commit 04f9f068a6 ("regulator: s5m8767: Modify parsing
method of the voltage table of buck2/3/4") broke it because DVS voltage
won't be parsed from devicetree if DVS GPIO is not enabled. After the
change, driver will configure bucks to use the register reset value as
voltage which might have unpleasant effects.
Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled
in devicetree (therefore DVS voltage is also not parsed), explicitly
disable it.
Cc: <stable@vger.kernel.org>
Fixes: 04f9f068a6 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: Rob Herring <robh@kernel.org>
Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There are lots of fields in struct hi6421_spmi_pmic that aren't
used. As a matter of fact, only regmap is needed.
So, drop the struct as a whole, and set regmap as the drvdata.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/1828cb783b1ebca0b98bf0b3077d8701adb228f7.1630586862.git.mchehab+huawei@kernel.org
Consistently use the defines for buck control mask values.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/YVqpujZLZmaiqwe8@fedora
Signed-off-by: Mark Brown <broonie@kernel.org>
PM2250 is commonly used with QCM2290/QCS2290 SoCs, and provides 4 SMPS
and 22 LDO regulators. The LDO regulators are the same types found on
PM660.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210926084549.29880-3-shawn.guo@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
We lowered all the other constraint related log messages to debug level so
lower the logging of what supplies we're configuring to debug level too.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210929140717.3769-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
debugfs code complained at boot time that
debugfs: Directory 'reg-dummy-regulator-dummy' with parent 'regulator'
already present!
if we compile kernel with DEBUG_TEST_DRIVER_REMOVE. The problem is that we
don't provide .remove() method for dummy_regulator_driver, which should
invoke regulator_unregister() on device teardown to properly free things.
Though it's harmless as dummy_pdev never gets unbound in practice, let's
use devm_regulator_register() to get rid of the inconsistency.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Link: https://lore.kernel.org/r/20210925035507.1904-1-yuzenghui@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
devm_pwm_get() can return -EPROBE_DEFER if the pwm regulator is not
ready yet. Use dev_err_probe() for pwm regulator resources
to indicate the deferral reason when waiting for the
resource to come up.
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Link: https://lore.kernel.org/r/20210925173413.1019-1-linux.amoon@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
MAX8973 is supposed to be MAX8973A. Kconfig and the
initial comment of max8973-regulator.c were modified
accordingly.
Signed-off-by: Ramona Alexandra Nechita <ramona.nechita@analog.com>
Link: https://lore.kernel.org/r/20210920061137.10884-1-ramona.nechita@analog.com
Signed-off-by: Mark Brown <broonie@kernel.org>
i915 will soon gain an eviction path that trylock a whole lot of locks
for eviction, getting dmesg failures like below:
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48 max: 48!
48 locks held by i915_selftest/5776:
#0: ffff888101a79240 (&dev->mutex){....}-{3:3}, at: __driver_attach+0x88/0x160
#1: ffffc900009778c0 (reservation_ww_class_acquire){+.+.}-{0:0}, at: i915_vma_pin.constprop.63+0x39/0x1b0 [i915]
#2: ffff88800cf74de8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.63+0x5f/0x1b0 [i915]
#3: ffff88810c7f9e38 (&vm->mutex/1){+.+.}-{3:3}, at: i915_vma_pin_ww+0x1c4/0x9d0 [i915]
#4: ffff88810bad5768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
#5: ffff88810bad60e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
...
#46: ffff88811964d768 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
#47: ffff88811964e0e8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_gem_evict_something+0x110/0x860 [i915]
INFO: lockdep is turned off.
Fixing eviction to nest into ww_class_acquire is a high priority, but
it requires a rework of the entire driver, which can only be done one
step at a time.
As an intermediate solution, add an acquire context to
ww_mutex_trylock, which allows us to do proper nesting annotations on
the trylocks, making the above lockdep splat disappear.
This is also useful in regulator_lock_nested, which may avoid dropping
regulator_nesting_mutex in the uncontended path, so use it there.
TTM may be another user for this, where we could lock a buffer in a
fastpath with list locks held, without dropping all locks we hold.
[peterz: rework actual ww_mutex_trylock() implementations]
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/YUBGPdDDjKlxAuXJ@hirez.programming.kicks-ass.net
This reverts commit 0da6736ecd.
The MODULE_DEVICE_TABLE already creates proper alias. Having another
MODULE_ALIAS causes the alias to be duplicated:
$ modinfo max14577-regulator.ko
alias: platform:max77836-regulator
alias: platform:max14577-regulator
description: Maxim 14577/77836 regulator driver
alias: platform:max77836-regulator
alias: platform:max14577-regulator
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 0da6736ecd ("regulator: max14577: Add proper module aliases strings")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20210916144102.120980-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix 'enable' gpio control logic from the below cases if it's specified.
1. All off and both are sequentially controlled to be on.
The 'enable' gpio control block to be called twice including the delay time.
2. Both are on and one is preparing to be off.
The 'enable' gpio control low before register cache is configured to be true.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1631629249-9998-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Voltage-controlled regulators depend on their supply regulator for
retrieving their voltage, and so they might return -EPROBE_DEFER at this
stage. Our caller already attempts to resolve supplies and retry, so we
shouldn't be printing this error to logs.
Quiets log messages like this, on Rockchip RK3399 Gru/Kevin boards:
[ 1.033057] ppvar_bigcpu: failed to get the current voltage: -EPROBE_DEFER
...
[ 1.036735] ppvar_litcpu: failed to get the current voltage: -EPROBE_DEFER
...
[ 1.040366] ppvar_gpu: failed to get the current voltage: -EPROBE_DEFER
...
[ 1.044086] ppvar_centerlogic: failed to get the current voltage: -EPROBE_DEFER
Cc: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20210826124015.1.Iab79c6dd374ec48beac44be2fcddd165dd26476b@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210908105752.2035-1-caihuoqing@baidu.com
Signed-off-by: Mark Brown <broonie@kernel.org>
COMPILE_TEST is helpful to find compilation errors in other platform(e.g.X86).
In this case, the support of COMPILE_TEST is added, so this module could
be compiled in other platform(e.g.X86), without ARCH_SYNQUACER configuration.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210908105738.1933-1-caihuoqing@baidu.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap/devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210908105745.1984-1-caihuoqing@baidu.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix a typo in the pm8009 LDO7 declaration, it uses resource name ldo%s6
instead of ldo%s7.
Fixes: 951384cabc ("regulator: qcom-rpmh-regulator: add pm8009-1 chip revision")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210901114350.1106073-1-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
vctrl_enable() and vctrl_disable() call regulator_enable() and
regulator_disable(), respectively. However, vctrl_* are regulator ops
and should not be calling the locked regulator APIs. Doing so results in
a lockdep warning.
Instead of exporting more internal regulator ops, model the ctrl supply
as an actual supply to vctrl-regulator. At probe time this driver still
needs to use the consumer API to fetch its constraints, but otherwise
lets the regulator core handle the upstream supply for it.
The enable/disable/is_enabled ops are not removed, but now only track
state internally. This preserves the original behavior with the ops
being available, but one could argue that the original behavior was
already incorrect: the internal state would not match the upstream
supply if that supply had another consumer that enabled the supply,
while vctrl-regulator was not enabled.
The lockdep warning is as follows:
WARNING: possible circular locking dependency detected
5.14.0-rc6 #2 Not tainted
------------------------------------------------------
swapper/0/1 is trying to acquire lock:
ffffffc011306d00 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent (arch/arm64/include/asm/current.h:19
include/linux/ww_mutex.h:111
drivers/regulator/core.c:329)
but task is already holding lock:
ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
regulator_lock_recursive (drivers/regulator/core.c:156
drivers/regulator/core.c:263)
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (regulator_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
include/asm-generic/atomic-long.h:29
kernel/locking/mutex.c:103
kernel/locking/mutex.c:144
kernel/locking/mutex.c:963)
ww_mutex_lock (kernel/locking/mutex.c:1199)
regulator_lock_recursive (drivers/regulator/core.c:156
drivers/regulator/core.c:263)
regulator_lock_dependent (drivers/regulator/core.c:343)
regulator_enable (drivers/regulator/core.c:2808)
set_machine_constraints (drivers/regulator/core.c:1536)
regulator_register (drivers/regulator/core.c:5486)
devm_regulator_register (drivers/regulator/devres.c:196)
reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
platform_probe (drivers/base/platform.c:1427)
[...]
-> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
regulator_lock_dependent (include/linux/ww_mutex.h:129
drivers/regulator/core.c:329)
regulator_enable (drivers/regulator/core.c:2808)
set_machine_constraints (drivers/regulator/core.c:1536)
regulator_register (drivers/regulator/core.c:5486)
devm_regulator_register (drivers/regulator/devres.c:196)
reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
[...]
-> #0 (regulator_list_mutex){+.+.}-{3:3}:
__lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
kernel/locking/lockdep.c:3174 (discriminator 4)
kernel/locking/lockdep.c:3789 (discriminator 4)
kernel/locking/lockdep.c:5015 (discriminator 4))
lock_acquire (arch/arm64/include/asm/percpu.h:39
kernel/locking/lockdep.c:438
kernel/locking/lockdep.c:5627)
__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
include/asm-generic/atomic-long.h:29
kernel/locking/mutex.c:103
kernel/locking/mutex.c:144
kernel/locking/mutex.c:963)
mutex_lock_nested (kernel/locking/mutex.c:1125)
regulator_lock_dependent (arch/arm64/include/asm/current.h:19
include/linux/ww_mutex.h:111
drivers/regulator/core.c:329)
regulator_enable (drivers/regulator/core.c:2808)
vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
_regulator_do_enable (drivers/regulator/core.c:2617)
_regulator_enable (drivers/regulator/core.c:2764)
regulator_enable (drivers/regulator/core.c:308
drivers/regulator/core.c:2809)
_set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
dev_pm_opp_set_rate (drivers/opp/core.c:1164)
set_target (drivers/cpufreq/cpufreq-dt.c:62)
__cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
drivers/cpufreq/cpufreq.c:2271)
cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
subsys_interface_register (drivers/base/bus.c:?)
cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> regulator_ww_class_acquire --> regulator_ww_class_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(regulator_ww_class_mutex);
lock(regulator_ww_class_acquire);
lock(regulator_ww_class_mutex);
lock(regulator_list_mutex);
*** DEADLOCK ***
6 locks held by swapper/0/1:
#0: ffffff8002d32188 (&dev->mutex){....}-{3:3}, at:
__device_driver_lock (drivers/base/dd.c:1030)
#1: ffffffc0111a0520 (cpu_hotplug_lock){++++}-{0:0}, at:
cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2792 (discriminator 2))
#2: ffffff8002a8d918 (subsys mutex#9){+.+.}-{3:3}, at:
subsys_interface_register (drivers/base/bus.c:1033)
#3: ffffff800341bb90 (&policy->rwsem){+.+.}-{3:3}, at:
cpufreq_online (include/linux/bitmap.h:285
include/linux/cpumask.h:405
drivers/cpufreq/cpufreq.c:1399)
#4: ffffffc011f0b7b8 (regulator_ww_class_acquire){+.+.}-{0:0}, at:
regulator_enable (drivers/regulator/core.c:2808)
#5: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
regulator_lock_recursive (drivers/regulator/core.c:156
drivers/regulator/core.c:263)
stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc6 #2 7c8f8996d021ed0f65271e6aeebf7999de74a9fa
Hardware name: Google Scarlet (DT)
Call trace:
dump_backtrace (arch/arm64/kernel/stacktrace.c:161)
show_stack (arch/arm64/kernel/stacktrace.c:218)
dump_stack_lvl (lib/dump_stack.c:106 (discriminator 2))
dump_stack (lib/dump_stack.c:113)
print_circular_bug (kernel/locking/lockdep.c:?)
check_noncircular (kernel/locking/lockdep.c:?)
__lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
kernel/locking/lockdep.c:3174 (discriminator 4)
kernel/locking/lockdep.c:3789 (discriminator 4)
kernel/locking/lockdep.c:5015 (discriminator 4))
lock_acquire (arch/arm64/include/asm/percpu.h:39
kernel/locking/lockdep.c:438
kernel/locking/lockdep.c:5627)
__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
include/asm-generic/atomic-long.h:29
kernel/locking/mutex.c:103
kernel/locking/mutex.c:144
kernel/locking/mutex.c:963)
mutex_lock_nested (kernel/locking/mutex.c:1125)
regulator_lock_dependent (arch/arm64/include/asm/current.h:19
include/linux/ww_mutex.h:111
drivers/regulator/core.c:329)
regulator_enable (drivers/regulator/core.c:2808)
vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
_regulator_do_enable (drivers/regulator/core.c:2617)
_regulator_enable (drivers/regulator/core.c:2764)
regulator_enable (drivers/regulator/core.c:308
drivers/regulator/core.c:2809)
_set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
dev_pm_opp_set_rate (drivers/opp/core.c:1164)
set_target (drivers/cpufreq/cpufreq-dt.c:62)
__cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
drivers/cpufreq/cpufreq.c:2271)
cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
subsys_interface_register (drivers/base/bus.c:?)
cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
[...]
Reported-by: Brian Norris <briannorris@chromium.org>
Fixes: f8702f9e4a ("regulator: core: Use ww_mutex for regulators locking")
Fixes: e915331149 ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In commit e915331149 ("regulator: vctrl-regulator: Avoid deadlock getting
and setting the voltage"), all calls to get/set the voltage of the
control regulator were switched to unlocked versions to avoid deadlocks.
However, the call in the probe path is done without regulator locks
held. In this case the locked version should be used.
Switch back to the locked regulator_get_voltage() in the probe path to
avoid any mishaps.
Fixes: e915331149 ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The helper to send IRQ notification for regulator errors had still
old description mentioning calling BUG() as a last resort when
error status reading has kept failing for more times than a given
threshold.
The impementation calling BUG() did never end-up in-tree but was
replaced by hopefully more sophisticated handler trying to power-off
the system.
Fix the documentation to reflect actual behaviour.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210823075651.GA3717293@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
From testing on hardware the poll_enable_time isn't required and
sometimes causes the driver probe to fail so let's remove it.
Signed-off-by: Alistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210803084456.198-5-alistair@alistair23.me
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently. Since the register map
is small, we use a FLAT regmap cache.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20210803165211.3b00db29@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
Enable regmap cache to reduce i2c transactions and corresponding
interrupts if regulator is accessed frequently. Since the register map
is small -- there's only one register in sy8824c and sy8824e, there
are only two registers in sy20276 and sy20278, so we use a FLAT regmap
cache.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Link: https://lore.kernel.org/r/20210803165043.042ec24d@xhacker.debian
Signed-off-by: Mark Brown <broonie@kernel.org>
The arrays containing the regulator's voltage ranges are
currently named after the first ldo which uses such range.
However, it sounds a lot clearer if those are named with
the voltage range instead.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/1bdff1d1f23753b69c8044160decfad1e8553d08.1627121912.git.mchehab+huawei@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of returning error directly, use dev_err_probe. This avoids
messages in the dmesg log for devices which will be probed again later.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20210721165716.19915-1-macroalpha82@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Reg will be reset in below two conditions.
1. 'Enable' pin from H to L.
2. Both PAVDD and NAVDD are all disabled.
And 'Enable' pin also control i2c communication capability.
This patch is to Seperate the if condition in enable/disable callback for
reg cache manipulation.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Link: https://lore.kernel.org/r/1626407746-23156-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In addition to the ability of merging some power outputs, this chip has
an overdrive mode.
BCORE1, BCORE2 and BPRO have this ability, in which case the legal
current draw is increased from 2 amps to 2.5 amps (at the expense of
a quiescent current increase), and the configurable current limits
are doubled.
If a current higher than maximum half-current mode is requested, enable
overdrive, and scale the current limit down.
Symmetrically, scale the current limit up when querying a overdrive-enabled
regulator.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Link: https://lore.kernel.org/r/824518e6391b783a12eba9ff0527f06607a34bfb.1626160826.git.plr.vincent@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't populate the const array func_base on the stack but instead it
static. Makes the object code smaller by 55 bytes:
Before:
text data bss dec hex filename
6422 3216 64 9702 25e6 drivers/regulator/rt6245-regulator.o
After:
text data bss dec hex filename
6303 3280 64 9647 25af drivers/regulator/rt6245-regulator.o
Reduction of 55 bytes
(gcc version 10.3.0)
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20210715141531.27672-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These APIs aren't used anywhere and most-likely exist because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.
For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.
Removing these discourages any weird logic that could be created with
such an API functions.
Alexandru Ardelean (4):
regulator: devres: remove devm_regulator_unregister_notifier()
function
regulator: devres: remove devm_regulator_unregister() function
regulator: devres: remove
devm_regulator_bulk_unregister_supply_alias()
regulator: devres: unexport devm_regulator_unregister_supply_alias()
drivers/regulator/devres.c | 105 +----------------------------
include/linux/regulator/consumer.h | 23 -------
include/linux/regulator/driver.h | 1 -
3 files changed, 2 insertions(+), 127 deletions(-)
--
2.31.1
The ROHM BD71837/47/50/78 do support enabling/disabling the under/over
voltage protection. Add support for enabling/disabling the protection
according to the device-tree information.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210705105416.GA1189560@localhost.localdomain
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of linear mapping, Use linear range to map all voltage selection.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/1625553939-9109-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The TPS65910 regulator now gets a deferred probe until supply regulator is
registered. Silence noisy error message about the deferred probe.
Reported-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210705201211.16082-1-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The shift setting can be calculated via the corresponding mask field,
so remove these shift fields.
The usage of da_vsel_mask is different from other mask defines because
current code does shift regval before mask with the da_vsel_mask.
Do proper shit to da_vsel_mask setting so we can calculate the shift.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210629130503.2183574-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This API hook isn't used anywhere outside of the regulator devres code.
This function is needed for the devm_regulator_bulk_register_supply_alias()
function on the error path, to cleanup any previously registered supply
aliases.
This change makes the devm_regulator_unregister_supply_alias() local to the
regulator core framework, to avoid it being used in any weird logic.
It's also removing the doc-string for
devm_regulator_unregister_supply_alias(), since it doesn't need to be
documented anymore, as no other external consumer should use it.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625122324.327585-5-aardelean@deviqon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.
For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.
Removing this also discourages any weird logic that could be created with
such an API function.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625122324.327585-4-aardelean@deviqon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.
For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.
Removing this also discourages any weird logic that could be created with
such an API function.
Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210625122324.327585-3-aardelean@deviqon.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since config.dev = pdev->dev.parent in current code, so
dev_get_drvdata(rdev->dev.parent) call in hi6421_regulator_enable
returns the drvdata of the mfd device rather than the regulator. Fix it.
This was broken while converting to use simplified DT parsing because the
config.dev changed from pdev->dev to pdev->dev.parent for parsing the
parent's of_node.
Fixes: 29dc269a85 ("regulator: hi6421: Convert to use simplified DT parsing")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210630095959.2411543-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If use dev->parent, the regulator_unregister will not be called when this
driver is unloaded. Fix it by using dev instead.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210702142140.2678130-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Since config.dev = pdev->dev.parent in current code, so
dev_get_drvdata(rdev->dev.parent) actually returns the drvdata of the mfd
device rather than the regulator. Fix it.
Fixes: 9bc146acc3 ("regulator: hi6421v600: Fix setting wrong driver_data")
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Tested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/20210630074246.2305166-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix wrong mask for strobe-polarity-high.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
In-reply-to: <CAFRkauB=0KwrJW19nJTTagdHhBR=V2R8YFWG3R3oVXt=rBRsqw@mail.gmail.com>
Reviewed-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/1624723112-26653-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The boolean variable may_have_irqs is not ininitialized and is
only being set to true in the case where chip is ROHM_CHIP_TYPE_BD9576.
Fix this by ininitialized may_have_irqs to false.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: e7bf1fa58c ("regulator: bd9576: Support error reporting")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/20210622144730.22821-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Use DIV_ROUND_UP to prevent truncation by integer division issue.
This ensures we return enough delay time.
Also fix returning negative value when new_sel < old_sel.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code set "config.driver_data = sreg" but sreg only init the mutex,
the othere fields are just zero. Fix it by pass *info to config.driver_data
so each regulator can get corresponding data by rdev_get_drvdata().
Separate enable_mutex from struct hi6421_spmi_reg_info since only need one
mutex for the driver.
Fixes: d2dfd50a0b ("staging: hikey9xx: hi6421v600-regulator: move LDO config from DT")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210622043329.392072-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Changes since v2:
-----------------
- v2 series can be found here: https://lore.kernel.org/linux-arm-msm/20210615074543.26700-1-bhupesh.sharma@linaro.org/T/#m8303d27d561b30133992da88198abb78ea833e21
- Addressed review comments from Bjorn and Mark.
- As per suggestion from Bjorn, seperated the patches in different
patchsets (specific to each subsystem) to ease review and patch application.
Changes since v1:
-----------------
- v1 series can be found here: https://lore.kernel.org/linux-arm-msm/20210607113840.15435-1-bhupesh.sharma@linaro.org/T/#mc524fe82798d4c4fb75dd0333318955e0406ad18
- Addressed review comments from Bjorn and Vinod received on the v1
series.
This series adds the regulator support code for SA8155p-adp board
which is based on Qualcomm snapdragon sa8155p SoC which in turn is
simiar to the sm8150 SoC.
This board supports a new PMIC PMM8155AU.
While at it, also make some cosmetic changes to the regulator driver
and dt-bindings to make sure the compatibles are alphabetical and also
fix issues with extra comma(s) at the end of terminator line(s).
Cc: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Bhupesh Sharma (5):
dt-bindings: regulator: qcom,rpmh-regulator: Arrange compatibles
alphabetically
dt-bindings: regulator: qcom,rpmh-regulator: Add compatible for
SA8155p-adp board pmic
regulator: qcom-rpmh: Cleanup terminator line commas
regulator: qcom-rpmh: Add terminator at the end of pm7325x_vreg_data[]
array
regulator: qcom-rpmh: Add new regulator found on SA8155p adp board
.../regulator/qcom,rpmh-regulator.yaml | 17 ++---
drivers/regulator/qcom-rpmh-regulator.c | 62 +++++++++++++++----
2 files changed, 59 insertions(+), 20 deletions(-)
--
2.31.1
Extend regulator notification support
This series extends the regulator notification and error flag support.
Initial discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.camel@fi.rohmeurope.com/
In a nutshell - the series adds:
1. WARNING level events/error flags. (Patch 3)
Current regulator 'ERROR' event notifications for over/under
voltage, over current and over temperature are used to indicate
condition where monitored entity is so badly "off" that it actually
indicates a hardware error which can not be recovered. The most
typical hanling for that is believed to be a (graceful)
system-shutdown. Here we add set of 'WARNING' level flags to allow
sending notifications to consumers before things are 'that badly off'
so that consumer drivers can implement recovery-actions.
2. Device-tree properties for specifying limit values. (Patches 1, 5)
Add limits for above mentioned 'ERROR' and 'WARNING' levels (which
send notifications to consumers) and also for a 'PROTECTION' level
(which will be used to immediately shut-down the regulator(s) W/O
informing consumer drivers. Typically implemented by hardware).
Property parsing is implemented in regulator core which then calls
callback operations for limit setting from the IC drivers. A
warning is emitted if protection is requested by device tree but the
underlying IC does not support configuring requested protection.
3. Helpers which can be registered by IC. (Patch 4)
Target is to avoid implementing IRQ handling and IRQ storm protection
in each IC driver. (Many of the ICs implementin these IRQs do not allow
masking or acking the IRQ but keep the IRQ asserted for the whole
duration of problem keeping the processor in IRQ handling loop).
4. Emergency poweroff function (refactored out of the thermal_core to
kernel/reboot.c) which is called if IC fires error IRQs but IC reading
fails and given retry-count is exceeded. (Patches 2, 4)
Please note that the mutex in the emergency shutdown was replaced by a
simple atomic in order to allow call from any context.
The helper was attempted to be done so it could be used to implement
roughly same logic as is used in qcom-labibb regulator. This means
amongst other things a safety shut-down if IC registers are not readable.
Using these shut-down retry counters are optional. The idea is that the
helper could be also used by simpler ICs which do not provide status
register(s) which can be used to check if error is still active.
ICs which do not have such status register can simply omit the 'renable'
callback (and retry-counts etc) - and helper assumes the situation is Ok
and re-enables IRQ after given time period. If problem persists the
handler is ran again and another notification is sent - but at least the
delay allows processor to avoid IRQ loop.
Patch 7 takes this notification support in use at BD9576MUF.
Patch 8 is related to MFD change which is not really related to the RFC
here. It was added to this series in order to avoid potential conflicts.
Patch 9 adds a maintainers entry.
Changelog v10-RESEND:
- rebased on v5.13-rc4
Changelog v10:
- rebased on v5.13-rc2
- Move rdev_*() print macros to the internal.h and use rdev_dbg()
from irq_helpers.c
- Export rdev_get_name() and move it from coupler.h to driver.h for
others to use. (It was already in coupler.h but not exported -
usage was limited and coupler.h does not sound like optimal place
as rdev_name is not only used by coupled regulators)
- Send all regulator notifications from irq_helpers.c at one OR'd
event for the sake of simplicity. For BD9576 this does not matter
as it has own IRQ for each event case. Header defining events says
they may be OR'd.
- Change WARN() at protection shutdown to pr_emerg as suggested by
Petr.
Changelog v9:
- rebases on v5.13-rc1
- Update thermal documentation
- Fix regulator notification event number
Changelog v8:
- split shutdown API adding and thermal core taking it in use to
own patches.
- replace the spinlock with atomic when ensuring the emergency
shutdown is only called once.
Changelog v7:
general:
- rebased on v5.12-rc7
- new patch for refactoring the hw-failure reboot logic out of
thermal_core.c for others to use.
notification helpers:
- fix regulator error_flags query
- grammar/typos
- do not BUG() but attempt to shut-down the system
- use BITS_PER_TYPE()
Changelog v6:
Add MAINTAINERS entry
Changes to IRQ notifiers
- move devm functions to drivers/regulator/devres.c
- drop irq validity check
- use devm_add_action_or_reset()
- fix styling issues
- fix kerneldocs
Changelog v5:
- Fix the badly formatted pr_emerg() call.
Changelog v4:
- rebased on v5.12-rc6
- dropped RFC
- fix external FET DT-binding.
- improve prints for cases when expecting HW failure.
- styling and typos
Changelog v3:
Regulator core:
- Fix dangling pointer access at regulator_irq_helper()
stpmic1_regulator:
- fix function prototype (compile error)
bd9576-regulator:
- Update over current limits to what was given in new data-sheet
(REV00K)
- Allow over-current monitoring without external FET. Set limits to
values given in data-sheet (REV00K).
Changelog v2:
Generic:
- rebase on v5.12-rc2 + BD9576 series
- Split devm variant of delayed wq to own series
Regulator framework:
- Provide non devm variant of IRQ notification helpers
- shorten dt-property names as suggested by Rob
- unconditionally call map_event in IRQ handling and require it to be
populated
BD9576 regulators:
- change the FET resistance property to micro-ohms
- fix voltage computation in OC limit setting
BD9573 and BD9576 support set of "protection" interrupts for "fatal"
issues. Those lead to SOC reset as PMIC shuts the power outputs. Thus
there is no relevant IRQ handling for them.
Few "detection" interrupts were added to the BD9576 with the idea that
SOC could take some recovery-action before error gets unrecoverable.
Add support for over and under voltage detection for Vout1 ... Vout4
and VoutL1. Add over-current detection for VoutS1 and finally a
thermal warning (common for all regulators) which alerts 30 C
before temperature reaches the thermal shutdown point. This way
consumer drivers can build error-recovery mechanisms.
Unfortunately the BD9576 interrupt logic was not re-evaluated. IRQs
are not designed to be properly acknowleged - and IRQ line is kept
active for whole duration of error condition (in comparison to
informing only about state change).
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/05c4f7a8e30ef1d4d5f3ceab07da4ebe68f5b4ed.1622628334.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Provide helper function for IC's implementing regulator notifications
when an IRQ fires. The helper also works for IRQs which can not be acked.
Helper can be set to disable the IRQ at handler and then re-enabling it
on delayed work later. The helper also adds regulator_get_error_flags()
errors in cache for the duration of IRQ disabling.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The rdev print helpers are a nice way to print messages related to a
specific regulator device. Move them from core.c to internal.h
As the rdev print helpers use rdev_get_name() export it from core.c. Also
move the declaration from coupler.h to driver.h because the rdev name is
not just a coupled regulator property. I guess the main audience for
rdev_get_name() will be the regulator core and drivers.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Link: https://lore.kernel.org/r/dc7fd70dc31de4d0e820b7646bb78eeb04f80735.1622628333.git.matti.vaittinen@fi.rohmeurope.com
Signed-off-by: Mark Brown <broonie@kernel.org>
commit db27f8294c changed eco_mode << (ffs(sreg->eco_mode_mask) - 1)
to sreg->eco_mode_mask << (ffs(sreg->eco_mode_mask) - 1) which is wrong.
Fix it by simply set val = sreg->eco_mode_mask.
In additional, sreg->eco_mode_mask can be 0 (LDO3, LDO33, LDO34).
Return -EINVAL if idle mode is not supported when sreg->eco_mode_mask is 0.
While at it, also use unsigned int for reg_val/val which is the expected
type for regmap_read and regmap_update_bits.
Fixes: db27f8294c ("staging: regulator: hi6421v600-regulator: use shorter names for OF properties")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210619123423.4091429-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SA8155p-adp board supports a new regulator - pmm8155au.
The output power management circuits in this regulator include:
- FTS510 smps,
- HFS510 smps, and
- LDO510 linear regulators
Add support for the same.
Cc: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210617051712.345372-6-bhupesh.sharma@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Add missing terminator(s) at the end of pm7325x_vreg_data[]
array instances.
Fixes: c4e5aa3dbe ("regulator: qcom-rpmh: Add PM7325/PMR735A regulator support")
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Link: https://lore.kernel.org/r/20210617051712.345372-5-bhupesh.sharma@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Cleanup the qcom-rpmh regulator driver to remove comma(s)
at the end of the terminator line(s).
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Link: https://lore.kernel.org/r/20210617051712.345372-4-bhupesh.sharma@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Current code sets config.driver_data to a zero initialized regulator
which is obviously wrong. Fix it.
Fixes: 4618119b9b ("regulator: hi655x: enable regulator for hi655x PMIC")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20210620132715.60215-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of returning the the PTR_ERR directly, use dev_err_probe which
will also correctly set the deferred probe reason in
/sys/kernel/debug/deferred_devices, making it easier to debug missing
devices on the system.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Link: https://lore.kernel.org/r/20210616125331.153414-1-r.czerwinski@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
At the context with *rdev, use rdev_get_drvdata() is more intuitive.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210616034458.3499522-3-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
It's only used in this file and never changed, make it static const.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210616034458.3499522-2-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210616034458.3499522-1-axel.lin@ingics.com
Signed-off-by: Mark Brown <broonie@kernel.org>
