summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2021-11-08Merge tag 'mfd-next-5.16' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Removed Drivers: - Remove support for TI TPS80031/TPS80032 PMICs New Device Support: - Add support for Magnetic Reader to TI AM335x - Add support for DA9063_EA to Dialog DA9063 - Add support for SC2730 PMIC to Spreadtrum SC27xx - Add support for MacBookPro16,2 ICL-N UART Intel LPSS PCI - Add support for lots of new PMICS in QCom SPMI PMIC - Add support for ADC to Diolan DLN2 New Functionality: - Add support for Power Off to Rockchip RK817 Fix-ups: - Simplify Regmap passing to child devices in hi6421-spmi-pmic - SPDX licensing updates in ti_am335x_tscadc - Improve error handling in ti_am335x_tscadc - Expedite clock search in ti_am335x_tscadc - Generic simplifications in ti_am335x_tscadc - Use generic macros/defines in ti_am335x_tscadc - Remove unused code in ti_am335x_tscadc, cros_ec_dev - Convert to GPIOD in wcd934x - Add namespacing in ti_am335x_tscadc - Restrict compilation to relevant arches in intel_pmt - Provide better description/documentation in exynos_lpass - Add SPI device ID table in altera-a10sr, motorola-cpcap, sprd-sc27xx-spi - Change IRQ handling in qcom-pm8xxx - Split out I2C and SPI code in arizona - Explicitly include used headers in altera-a10sr - Convert sysfs show() function to in sysfs_emit - Standardise *_exit() and *_remove() return values in mc13xxx, stmpe, tps65912 - Trivial (style/spelling/whitespace) fixups in ti_am335x_tscadc, qcom-spmi-pmic, max77686-private - Device Tree fix-ups in ti,am3359-tscadc, samsung,s2mps11, samsung,s2mpa01, samsung,s5m8767, brcm,misc, brcm,cru, syscon, qcom,tcsr, xylon,logicvc, max77686, x-powers,ac100, x-powers,axp152, x-powers,axp209-gpio, syscon, qcom,spmi-pmic Bug Fixes: - Balance refcounting (get/put) in ti_am335x_tscadc, mfd-core - Fix IRQ trigger type in sec-irq, max77693, max14577 - Repair off-by-one in altera-sysmgr - Add explicit 'select MFD_CORE' to MFD_SIMPLE_MFD_I2C" * tag 'mfd-next-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (95 commits) mfd: simple-mfd-i2c: Select MFD_CORE to fix build error mfd: tps80031: Remove driver mfd: max77686: Correct tab-based alignment of register addresses mfd: wcd934x: Replace legacy gpio interface for gpiod dt-bindings: mfd: qcom: pm8xxx: Add pm8018 compatible mfd: dln2: Add cell for initializing DLN2 ADC mfd: qcom-spmi-pmic: Add missing PMICs supported by socinfo mfd: qcom-spmi-pmic: Document ten more PMICs in the binding mfd: qcom-spmi-pmic: Sort compatibles in the driver mfd: qcom-spmi-pmic: Sort the compatibles in the binding mfd: janz-cmoio: Replace snprintf in show functions with sysfs_emit mfd: altera-a10sr: Include linux/module.h mfd: tps65912: Make tps65912_device_exit() return void mfd: stmpe: Make stmpe_remove() return void mfd: mc13xxx: Make mc13xxx_common_exit() return void dt-bindings: mfd: syscon: Add samsung,exynosautov9-sysreg compatible mfd: altera-sysmgr: Fix a mistake caused by resource_size conversion dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema dt-bindings: mfd: syscon: Add rk3368 QoS register compatible mfd: arizona: Split of_match table into I2C and SPI versions ...
2021-11-05Merge branches 'ib-mfd-iio-touchscreen-clk-5.16', ↵Lee Jones2-17/+14
'ib-mfd-misc-regulator-5.16' and 'tb-mfd-from-regulator-5.16' into ibs-for-mfd-merged
2021-11-02Merge tag 'regulator-v5.16' of ↵Linus Torvalds18-897/+179
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 ...
2021-11-01Merge tag 'locking-core-2021-10-31' of ↵Linus Torvalds1-1/+1
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 ...
2021-10-23Merge series "Remove TPS80031 driver" from Dmitry Osipenko <digetx@gmail.com>:Mark Brown3-763/+0
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
2021-10-23regulator: Don't error out fixed regulator in regulator_sync_voltage()Dmitry Osipenko1-0/+3
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>
2021-10-23regulator: tps80031: Remove driverDmitry Osipenko3-763/+0
Driver was upstreamed in 2013 and never got a user, remove it. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20211021192258.21968-3-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-23regulator: Fix SY7636A breakageMark Brown1-0/+1
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>
2021-10-22Merge series "regulator: Introduce UniPhier NX1 SoC support" from Kunihiko ↵Mark Brown1-0/+4
Hayashi <hayashi.kunihiko@socionext.com>: 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
2021-10-22Merge series "Initial Fairphone 4 support" from Luca Weiss <luca@z3ntu.xyz>:Mark Brown1-0/+32
This series adds basic support for the recently announced Fairphone 4 smartphone, based on the Snapdragon 750G (sm7225). This adds support for UART, power & volume buttons, screen based on simple-framebuffer, regulators and USB. v2 fixes some stylistic problems in dts and corrects the situation with pm6350 regulator supplies. Luca Weiss (11): clk: qcom: add select QCOM_GDSC for SM6350 dt-bindings: regulator: qcom,rpmh: Add compatible for PM6350 regulator: qcom-rpmh: Add PM6350 regulators dt-bindings: pinctrl: qcom,pmic-gpio: Add compatible for PM6350 pinctrl: qcom: spmi-gpio: Add compatible for PM6350 arm64: dts: qcom: Add PM6350 PMIC arm64: dts: qcom: sm6350: add debug uart dt-bindings: arm: cpus: Add Kryo 570 CPUs dt-bindings: arm: qcom: Document sm7225 and fairphone,fp4 board arm64: dts: qcom: Add SM7225 device tree arm64: dts: qcom: sm7225: Add device tree for Fairphone 4 .../devicetree/bindings/arm/cpus.yaml | 1 + .../devicetree/bindings/arm/qcom.yaml | 6 + .../bindings/pinctrl/qcom,pmic-gpio.yaml | 2 + .../regulator/qcom,rpmh-regulator.yaml | 2 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/pm6350.dtsi | 54 +++ arch/arm64/boot/dts/qcom/sm6350.dtsi | 31 ++ .../boot/dts/qcom/sm7225-fairphone-fp4.dts | 320 ++++++++++++++++++ arch/arm64/boot/dts/qcom/sm7225.dtsi | 16 + drivers/clk/qcom/Kconfig | 1 + drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 + drivers/regulator/qcom-rpmh-regulator.c | 32 ++ 12 files changed, 467 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/pm6350.dtsi create mode 100644 arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts create mode 100644 arch/arm64/boot/dts/qcom/sm7225.dtsi -- 2.33.0
2021-10-22Merge series "Add support for the silergy,sy7636a" from Alistair Francis ↵Mark Brown2-2/+1
<alistair@alistair23.me>: v13: - Address comments on thermal driver - Rebase on master (without other patches) v12: - Rebase v11: - Address comments on hwmon - Improve "mfd: simple-mfd-i2c: Add a Kconfig name" commit message v10: - Use dev_get_regmap() instead of dev_get_drvdata() v9: - Convert to use the simple-mfd-i2c instead Alistair Francis (9): dt-bindings: mfd: Initial commit of silergy,sy7636a.yaml mfd: simple-mfd-i2c: Add a Kconfig name mfd: simple-mfd-i2c: Enable support for the silergy,sy7636a regulator: sy7636a: Remove requirement on sy7636a mfd thermal: sy7636a: Add thermal driver for sy7636a hwmon: sy7636a: Add temperature driver for sy7636a ARM: imx_v6_v7_defconfig: Enable silergy,sy7636a ARM: dts: imx7d: remarkable2: Enable silergy,sy7636a ARM: dts: imx7d: remarkable2: Enable lcdif .../bindings/mfd/silergy,sy7636a.yaml | 79 ++++++++++ Documentation/hwmon/sy7636a-hwmon.rst | 24 ++++ arch/arm/boot/dts/imx7d-remarkable2.dts | 136 ++++++++++++++++++ arch/arm/configs/imx_v6_v7_defconfig | 4 + drivers/hwmon/Kconfig | 9 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/sy7636a-hwmon.c | 75 ++++++++++ drivers/mfd/Kconfig | 2 +- drivers/mfd/simple-mfd-i2c.c | 12 ++ drivers/regulator/Kconfig | 1 - drivers/regulator/sy7636a-regulator.c | 2 +- drivers/thermal/Kconfig | 6 + drivers/thermal/Makefile | 1 + drivers/thermal/sy7636a_thermal.c | 94 ++++++++++++ include/linux/mfd/sy7636a.h | 41 ++++++ 15 files changed, 484 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml create mode 100644 Documentation/hwmon/sy7636a-hwmon.rst create mode 100644 drivers/hwmon/sy7636a-hwmon.c create mode 100644 drivers/thermal/sy7636a_thermal.c create mode 100644 include/linux/mfd/sy7636a.h -- 2.31.1
2021-10-21regulator: uniphier: Add USB-VBUS compatible string for NX1 SoCKunihiko Hayashi1-0/+4
Add basic support for UniPhier NX1 SoC. This includes a compatible string and the same SoC-dependent data as PXs2 SoC. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1634520605-16583-3-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-21regulator: qcom-rpmh: Add PM6350 regulatorsLuca Weiss1-0/+32
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>
2021-10-21regulator: sy7636a: Remove requirement on sy7636a mfdAlistair Francis2-2/+1
Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20211015122551.38951-5-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-21regulator: tps62360: replacing legacy gpio interface for gpiodMaíra Canal1-33/+26
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>
2021-10-21regulator: lp872x: Remove lp872x_dvs_stateNathan Chancellor1-7/+7
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: 72bf80cf09c4 ("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>
2021-10-21Merge tag 'tags/s2m_s5m_dtschema' into tb-mfd-from-regulator-5.16Lee Jones1-12/+9
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>
2021-10-18Merge tag 'v5.15-rc6' into regulator-5.16Mark Brown1-2/+0
Linux 5.15-rc6
2021-10-16regulator: lp872x: replacing legacy gpio interface for gpiodMaíra Canal1-23/+15
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>
2021-10-08Merge series "regulator/mfd/clock: dt-bindings: Samsung S2M and S5M to ↵Mark Brown1-12/+9
dtschema" from Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>: 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
2021-10-08regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is ↵Krzysztof Kozlowski1-12/+9
disabled The driver and its bindings, before commit 04f9f068a619 ("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 04f9f068a619 ("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: 04f9f068a619 ("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>
2021-10-05mfd: hi6421-spmi-pmic: Cleanup drvdata to only include regmapMauro Carvalho Chehab1-5/+5
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
2021-10-04regulator: bd71815: Use defined mask valuesMatti Vaittinen1-2/+2
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>
2021-10-02regulator: qcom_smd: Add PM2250 regulatorsShawn Guo1-0/+49
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>
2021-09-30regulator: Lower priority of logging when setting supplyMark Brown1-1/+1
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>
2021-09-27regulator: dummy: Use devm_regulator_register()Zenghui Yu1-1/+2
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>
2021-09-27regulator: pwm-regulator: Make use of the helper function dev_err_probe()Anand Moon1-9/+3
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>
2021-09-20regulator: fix typo in Kconfig and max8973-regulatorRamona Alexandra Nechita2-4/+4
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>
2021-09-17kernel/locking: Add context to ww_mutex_trylock()Maarten Lankhorst1-1/+1
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
2021-09-17regulator: max14577: Revert "regulator: max14577: Add proper module aliases ↵Krzysztof Kozlowski1-2/+0
strings" This reverts commit 0da6736ecd10b45e535b100acd58df2db4c099d8. 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: 0da6736ecd10 ("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>
2021-09-15regulator: rtq6752: Enclose 'enable' gpio control by enable flagChiYuan Huang1-9/+9
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>
2021-09-13regulator: core: resolve supply voltage deferral silentlyBrian Norris1-3/+4
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>
2021-09-13regulator: vqmmc-ipq4019: Make use of the helper function ↵Cai Huoqing1-3/+1
devm_platform_ioremap_resource() 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>
2021-09-13regulator: ti-abb: Kconfig: Add helper dependency on COMPILE_TESTCai Huoqing1-1/+1
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>
2021-09-13regulator: ti-abb: Make use of the helper function devm_ioremap relatedCai Huoqing1-25/+6
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>
2021-09-01regulator: qcom-rpmh-regulator: fix pm8009-1 ldo7 resource nameDmitry Baryshkov1-1/+1
Fix a typo in the pm8009 LDO7 declaration, it uses resource name ldo%s6 instead of ldo%s7. Fixes: 951384cabc5d ("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>
2021-08-25regulator: vctrl: Avoid lockdep warning in enable/disable opsChen-Yu Tsai1-30/+42
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: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") Fixes: e9153311491d ("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>
2021-08-25regulator: vctrl: Use locked regulator_get_voltage in probe pathChen-Yu Tsai1-1/+2
In commit e9153311491d ("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: e9153311491d ("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>
2021-08-23regulator: Documentation fix for regulator error notification helperMatti Vaittinen1-1/+1
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>
2021-08-09regulator: sy7636a: Use the regmap directlyAlistair Francis1-7/+6
Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210806091058.141-6-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy7636a: Store the epd-pwr-good GPIO locallyAlistair Francis1-5/+16
Instead of storing the GPIO state in the mfd (where it isn't used) store it in the regulator. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210803084456.198-7-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy7636a: Use the parent driver dataAlistair Francis1-6/+6
Use the parent's MFD data instead of our data. Signed-off-by: Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210803084456.198-6-alistair@alistair23.me Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-03regulator: sy7636a: Remove the poll_enable_timeAlistair Francis1-3/+0
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>
2021-08-03regulator: sy8827n: Enable REGCACHE_FLATJisheng Zhang1-0/+14
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>
2021-08-03regulator: sy8824x: Enable REGCACHE_FLATJisheng Zhang1-1/+15
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>
2021-07-30regulator: rtq2134: Fix coding styleChiYuan Huang1-2/+2
Add empty space and put constant number to the right side for 'if' judgement. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/1627648326-5026-1-git-send-email-u0084500@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-26regulator: hi6421v600: rename voltage range arraysMauro Carvalho Chehab1-14/+14
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>
2021-07-26Merge branch 'regulator-5.14' into regulator-5.15Mark Brown2-27/+31
2021-07-26regulator: hi6421v600: use lowercase for ldoMauro Carvalho Chehab1-18/+18
As lowercase is generally preferred for node names, while it is not too late, change the LDO DT properties to lower case. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/395510cffeb39aebd1763cc5de1cb00a2c40e461.1627121912.git.mchehab+huawei@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-22regulator: fixed: use dev_err_probe for registerChris Morgan1-2/+3
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>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-18 09:45:00 +0300