summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2020-06-17regulator: mt6358: Remove BROKEN dependencyAxel Lin
The MFD part is merged into v5.8-rc1, thus remove BROKEN dependency. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20200616135030.1163660-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-17Merge tag 'v5.8-rc1' into regulator-5.8Mark Brown
Linux 5.8-rc1
2020-06-15regualtor: pfuze100: correct sw1a/sw2 on pfuze3000Robin Gong
PFUZE100_SWB_REG is not proper for sw1a/sw2, because enable_mask/enable_reg is not correct. On PFUZE3000, sw1a/sw2 should be the same as sw1a/sw2 on pfuze100 except that voltages are not linear, so add new PFUZE3000_SW_REG and pfuze3000_sw_regulator_ops which like the non-linear PFUZE100_SW_REG and pfuze100_sw_regulator_ops. Fixes: 1dced996ee70 ("regulator: pfuze100: update voltage setting for pfuze3000 sw1a") Reported-by: Christophe Meynard <Christophe.Meynard@ign.fr> Signed-off-by: Robin Gong <yibin.gong@nxp.com> Link: https://lore.kernel.org/r/1592171648-8752-1-git-send-email-yibin.gong@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-12regulator: Fix pickable ranges mappingMatti Vaittinen
Pickable ranges mapping function never used range min selector. Thus existing drivers broke when proper linear_ranges functionality was taken in use. Fix this for now just by ignoring the minimum selector. Fixes: 60ab7f4153b6 ("regulator: use linear_ranges helper") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200612090225.GA3243@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-12regulator: da9063: fix LDO9 suspend and warning.Martin Fuzzey
Commit 99f75ce66619 ("regulator: da9063: fix suspend") converted the regulators to use a common (corrected) suspend bit setting but one of regulators (LDO9) slipped through the crack. This means that the original problem was not fixed for LDO9 and also leads to a warning found by the test robot. da9063-regulator.c:515:3: warning: initialized field overwritten Fix this by converting that regulator too like the others. Fixes: 99f75ce66619 ("regulator: da9063: fix suspend") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/1591959073-16792-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-01Merge remote-tracking branch 'regulator/for-5.8' into regulator-linusMark Brown
2020-06-01Merge remote-tracking branch 'regulator/for-5.7' into regulator-linusMark Brown
2020-06-01regulator: max8998: max8998_set_current_limit() can be statickbuild test robot
Fixes: 4ffea5e083f8 ("regulator: max8998: Add charger regulator") Signed-off-by: kbuild test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20200530130314.GA73557@d7d8dbfb64ff Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29regulator: core: Add regulator bypass trace pointsCharles Keepax
Add new trace points for the start and end of enabling bypass on a regulator, to allow monitoring of when regulators are moved into bypass and how long that takes. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20200529152216.9671-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29Merge series "Fix regulators coupling for Exynos5800" from Marek Szyprowski ↵Mark Brown
<m.szyprowski@samsung.com>: Hi! This patchset is another attempt to fix the regulator coupling on Exynos5800/5422 SoCs. Here are links to the previous attempts: https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/ https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@samsung.com/ https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@linaro.org/ https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@samsung.com/ The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is handled by devfreq. CPUfreq initialized quite early during boot and it starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during boot goes down and some low-frequency OPPs are selected, what in turn causes lowering "vdd_arm". This happens before devfreq applies its requirements on "vdd_int". Regulator balancing code reduces "vdd_arm" voltage value, what in turn causes lowering "vdd_int" value to the lowest possible value. This is much below the operation point of the wcore bus, which still runs at the highest frequency. The issue was hard to notice because in the most cases the board managed to boot properly, even when the regulator was set to lowest value allowed by the regulator constraints. However, it caused some random issues, which can be observed as "Unhandled prefetch abort" or low USB stability. Adding more and more special cases to the generic code has been rejected, so the only way to ensure the desired behavior on Exynos5800-based SoCs is to make a custom regulator coupler driver. Best regards, Marek Szyprowski Patch summary: Marek Szyprowski (2): regulator: extract voltage balancing code to separate function soc: samsung: Add simple voltage coupler for Exynos5800 arch/arm/mach-exynos/Kconfig | 1 + drivers/regulator/core.c | 49 ++++++++------- drivers/soc/samsung/Kconfig | 3 + drivers/soc/samsung/Makefile | 1 + .../soc/samsung/exynos-regulator-coupler.c | 59 +++++++++++++++++++ include/linux/regulator/coupler.h | 8 +++ 6 files changed, 101 insertions(+), 20 deletions(-) create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c -- 2.17.1 base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
2020-05-29regulator: extract voltage balancing code to the separate functionMarek Szyprowski
Move the coupled regulators voltage balancing code to the separate function and allow to call it from the custom regulator couplers. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200529124940.10675-2-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-22regulator: max8998: Add charger regulatorJonathan Bakker
The max8998 has a current regulator for charging control. The charger driver in drivers/power/supply/max8998_charger.c has a comment in it stating that 'charger control is done by a current regulator "CHARGER"', but this regulator was never added until now. The current values have been extracted from a downstream driver for the SGH-T959V. Signed-off-by: Jonathan Bakker <xc-racer2@live.ca> Link: https://lore.kernel.org/r/BN6PR04MB0660E1F4A3D5A348BE88311CA3BA0@BN6PR04MB0660.namprd04.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20Merge series "MAINTAINER entries for few ROHM power devices" from Matti ↵Mark Brown
Vaittinen <matti.vaittinen@fi.rohmeurope.com>: Add maintainer entries to a few ROHM devices and Linear Ranges Linear Ranges helpers were refactored out of regulator core to lib so that other drivers could utilize them too. (I guess power/supply drivers and possibly clk drivers can benefit from them). As regulators is currently the main user it makes sense the changes to linear_ranges go through Mark's tree. During past two years few ROHM PMIC drivers have been added to mainstream. They deserve a supporter from ROHM side too :) Patch 1: Maintainer entries for few ROHM IC drivers Patch 2: Maintainer entry for linear ranges helpers --- Matti Vaittinen (2): MAINTAINERS: Add entry for ROHM power management ICs MAINTAINERS: Add maintainer entry for linear ranges helper MAINTAINERS | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) base-commit: b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce -- 2.21.0 -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~ Simon says - in Latin please. ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~ Thanks to Simon Glass for the translation =]
2020-05-14regulator: bd718x7: remove voltage change restriction from BD71847 LDOsMatti Vaittinen
The BD71837 had a HW "feature" where changing the regulator output voltages of other regulators but bucks 1-4 might cause spikes if regulators were enabled. Thus SW prohibit voltage changes for other regulators except for bucks 1-4 when regulator is enabled. The HW colleagues did inadvertly fix this issue for BD71847 and BD71850. The power-good detection for LDOs can still cause false alarms if LDO voltage is changed upwards when LDO is enabled. Allow LDO voltage changes and disabe the power-good monioring for the duration of the LDO voltage change and enable it after LDO voltage has stabilized. ROHM HW colleagues measured the safety limit of 1000uS for guaranteeing the voltage has stabilized. Let's use that for starters and add confiurable stabilization wait-time later if needed. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200513143921.GA22143@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-08Merge tag 'linear-ranges-lib' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.8 lib: Add linear ranges helper library and start using it Series extracts a "linear ranges" helper out of the regulator framework. Linear ranges helper is intended to help converting real-world values to register values when conversion is linear. I suspect this is useful also for power subsystem and possibly for clk.
2020-05-08regulator: use linear_ranges helperMatti Vaittinen
Change the regulator helpers to use common linear_ranges code. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/64f01d5e381b8631a271616b7790f9d5640974fb.1588944082.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-06regulator: db8500-prcmu: Use true,false for bool variableJason Yan
Fix the following coccicheck warning: drivers/regulator/db8500-prcmu.c:184:1-17: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200506061726.19289-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-29regulator: Revert "Use driver_deferred_probe_timeout for ↵John Stultz
regulator_init_complete_work" This reverts commit dca0b44957e5 ("regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work"), as we ended up reverting the default deferred_probe_timeout value back to zero, to preserve behavior with 5.6 we need to decouple the regulator timeout which was previously 30 seconds. This avoids breaking some systems that depend on the regulator timeout but don't require the deferred probe timeout. Cc: linux-pm@vger.kernel.org Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20200429172349.55979-1-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28regulator: bd718x7: remove voltage change restriction from BD71847Matti Vaittinen
The BD71837 had a HW "feature" where changing the regulator output voltages of other regulators but bucks 1-4 might cause spikes if regulators were enabled. Thus SW prohibit voltage changes for other regulators except for bucks 1-4 when regulator is enabled. The HW colleagues did inadvertly fix this issue for BD71847 and BD71850. Remove voltage change restrictions from other PMICs but BD71837. The LDO voltage changing is still restricted. I did not yet receive answer whether there is voltage spikes to be expected for LDOs. I only know that the power-good detection for LDOs can cause false alarms if LDO voltage is changed when LDO is enabled. We might be able to work-around this by disabling the power-good monioring for the duration of the LDO voltage change - but as I said, I don't know yet. Let's fix it later if we can confirm that also LDO voltage changes are safe. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20200428092930.GA9721@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-15regulator: qcom-rpmh: Fix typos in pm8150 and pm8150lBjorn Andersson
Fix typos in pm8150 l13/l16/l17 and pm8150l ldo8 supplies. Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200415053708.717623-1-bjorn.andersson@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: max77826: Add max77826 regulator driverIskren Chernev
Adding regulator driver for the Maxim max77826 device. The max77826 PMIC contains a high-efficiency BUCK regulator, a BUCK BOOST regulator and 15 LDOs. It is designed for smartphone and tablet applications and is accessed over I2C. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Link: https://lore.kernel.org/r/20200414172250.2363235-2-iskren.chernev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: tps80031: remove redundant assignment to variables ret and valColin Ian King
The variables ret and val are being initialized with values that are never read and are being updated later with a new value. The initializations are redundant and can be removed. Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Unused value") Link: https://lore.kernel.org/r/20200410133406.24458-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: ab8500: remove some defined but not used variablesJason Yan
Fix the following gcc warning: drivers/regulator/ab8500.c:195:27: warning: ‘ldo_vdmic_voltages’ defined but not used [-Wunused-const-variable=] static const unsigned int ldo_vdmic_voltages[] = { ^~~~~~~~~~~~~~~~~~ drivers/regulator/ab8500.c:169:27: warning: ‘fixed_3300000_voltage’ defined but not used [-Wunused-const-variable=] static const unsigned int fixed_3300000_voltage[] = { ^~~~~~~~~~~~~~~~~~~~~ drivers/regulator/ab8500.c:142:27: warning: ‘ldo_sdio_voltages’ defined but not used [-Wunused-const-variable=] static const unsigned int ldo_sdio_voltages[] = { ^~~~~~~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200410073343.39031-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: use consumer->supply_name in debugfs/regulator_summaryMichał Mirosław
Make it easier to identify regulator consumers when consumer device uses more than one supply. Before: regulator ena use open bypass voltage current min max ----------------------------------------------------------------------------------- regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV 1-0010 0mV 0mV 1-0010 0mV 0mV After: regulator ena use open bypass voltage current min max ----------------------------------------------------------------------------------- regulator-dummy 1 0 2 0 0mV 0mA 0mV 0mV 1-0010-vccio 0mV 0mV 1-0010-vcc33 0mV 0mV Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/731a4b299c6ae0ee9d8995157600a3477f21a36c.1585959068.git.mirq-linux@rere.qmqm.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2020-04-14regulator: qcom_rpm: remove defined but not used 'pm8921_ftsmps'Jason Yan
Fix the following gcc warning: drivers/regulator/qcom_rpm-regulator.c:607:34: warning: ‘pm8921_ftsmps’ defined but not used [-Wunused-const-variable=] static const struct qcom_rpm_reg pm8921_ftsmps = { ^~~~~~~~~~~~~ Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200409114026.38383-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-30Merge tag 'regulator-spi-v5.7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc Pull spi and regulator updates from Mark Brown: "At one point in the release cycle I managed to fat finger things and apply some SPI fixes onto a regulator branch and merge that into the SPI tree, then pull in a change shared with the MTD tree moving the Mediatek quadspi driver over to become the Mediatek spi-nor driver in the SPI tree. This has made a mess which I only just noticed while preparing this and I can't see a sensible way to unpick things due to other subsequent merge commits especially the pull from MTD so it looks like the most sensible thing to do is give up and combine the two pull requests. Fortunately both subsystems were fairly quiet this cycle, the highlights are: regulator: - Support for Monoloithic Power Systems MP5416, MP8867 and MPS8869 and Qualcomm PMI8994 and SMB208. SPI: - Lots of enhancements for spi-fsl-dspi, including XSPI mode support, from Vladimir Oltean. - Support for amlogic Meson G12A, IBM FSI, Mediatek spi-nor (moved from MTD), NXP i.MX8Mx, Rockchip PX30, RK3308 and RK3328, and Qualcomm Atheros AR934x/QCA95xx" * tag 'regulator-spi-v5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc: (118 commits) spi: efm32: Convert to use GPIO descriptors regulator: qcom_smd: Add pmi8994 regulator support regulator: da9063: Fix get_mode() functions to read sleep field spi: spi-fsl-lpspi: Replace zero-length array with flexible-array member spi: spi-s3c24xx: Replace zero-length array with flexible-array member spi: stm32: Fix comments compilation warnings spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses spi: spi-fsl-dspi: Add support for LS1028A spi: spi-fsl-dspi: Move invariant configs out of dspi_transfer_one_message spi: spi-fsl-dspi: Fix interrupt-less DMA mode taking an XSPI code path spi: spi-fsl-dspi: Avoid NULL pointer in dspi_slave_abort for non-DMA mode spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight spi: spi-fsl-dspi: Avoid reading more data than written in EOQ mode spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA mode spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR regulator: driver.h: fix regulator_map_* function names regulator: da9063: fix suspend spi: mxs: Drop GPIO includes ...
2020-03-24Merge branch 'regulator-5.7' into regulator-nextMark Brown
2020-03-24Merge branch 'regulator-5.6' into regulator-linusMark Brown
2020-03-24regulator: qcom_smd: Add pmi8994 regulator supportBjorn Andersson
The pmi8994 is commonly found on MSM8996 based devices, such as the Dragonboard 820c, where it supplies power to a number of LDOs on the primary PMIC. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200324041424.518160-1-bjorn.andersson@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-24regulator: da9063: Fix get_mode() functions to read sleep fieldAdam Thomson
get_mode() is used to retrieve the active mode state. Settings-A config is used during active state, whilst Settings-B is for suspend. This means we only need to check the sleep field of each buck and LDO as that field solely relates to Settings-A config. This change is a clone of the get_mode() update which was committed as part of: - regulator: da9062: fix suspend_enable/disable preparation [a72865f057820ea9f57597915da4b651d65eb92f] Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20200324092516.60B5C3FB8D@swsrvapps-01.diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18regulator: da9063: fix suspendMartin Fuzzey
The .set_suspend_enable() and .set_suspend_disable() methods are not supposed to immediately change the regulator state but just indicated if the regulator should be enabled or disabled when standby mode is entered (by a hardware signal). However currently they set control the SEL bits in the DVC registers, which causes the voltage to change to immediately between the "A" (normal) and "B" (standby) values as programmed and does nothing for the enable state... This means that "regulator-on-in-suspend" does not work (the regulator is switched off when the PMIC enters standby mode on the hardware signal) and, potentially, depending on the A and B voltage configurations the voltage could be incorrectly changed *before* actually entering suspend. The right bit to use for the functionality is the "CONF" bit in the "CONT" register. The detailed register description says "Sequencer target state" for this bit which is not very clear but the functional description is clearer. >From 5.1.5 System Enable: De-asserting SYS_EN (changing from active to passive state) clears control SYSTEM_EN which triggers a power down sequence into hibernate/standby mode ... With the exception of supplies that have the xxxx_CONF control bit asserted, all regulators in power domains POWER1, POWER, and SYSTEM are sequentially disabled in reverse order. Regulators with the <x>_CONF bit set remain on but change the active voltage controlregisters from V<x>_A to V<x>_B (if V<x>_B is notalready selected). Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group> Link: https://lore.kernel.org/r/1584461691-14344-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-16regulator: mp886x: add MP8867 supportJisheng Zhang
MP8867 is an I2C-controlled adjustable voltage regulator made by Monolithic Power Systems. The difference between MP8867 and MP8869 are: 1.If V_BOOT, the vref of MP8869 is fixed at 600mv while vref of MP8867 is determined by the I2C control. 2.For MP8867, when setting voltage, if the step is within 5, we need to manually set the GO BIT to 0. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200316223127.4b1ecc92@xhacker Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-16regulator: add support for MP8869 regulatorJisheng Zhang
The MP8869 from Monolithic Power Systems is a single output DC/DC converter. The voltage can be controlled via I2C. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200316223020.1a6d92ae@xhacker Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-13regulator: core: Avoid device name duplication in NORMAL_GETAndy Shevchenko
With current code: st-gyro-i2c i2c-PRP0001:00: i2c-PRP0001:00 supply vdd not found, using dummy regulator which looks a bit oververbose. Replace this with simplified format string for the above case, and drop "deviceless" case since for all dev_*() macros used in _regulator_get() the "(null)" will be printed anyway. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200312183245.1612-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-09Merge 5.6-rc5 into driver-core-nextGreg Kroah-Hartman
We need the driver core and debugfs changes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-06Merge tag 'regulator-fix-v5.6-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A couple of small fixes, one for a minor issue in the stm32-vrefbuf driver and a documentation fix in the Qualcomm code" * tag 'regulator-fix-v5.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: stm32-vrefbuf: fix a possible overshoot when re-enabling regulator: qcom_spmi: Fix docs for PM8004
2020-03-04regulator: Use driver_deferred_probe_timeout for regulator_init_complete_workJohn Stultz
The regulator_init_complete_work logic defers the cleanup for an arbitrary 30 seconds of time to allow modules loaded by userland to start. This arbitrary timeout is similar to the driver_deferred_probe_timeout value, and its been suggested we align these so users have a method to extend the timeouts as needed. So this patch changes the logic to use the driver_deferred_probe_timeout value for the delay value if it is set (using a delay of 0 if it is not). Cc: linux-pm@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Todd Kjos <tkjos@google.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Link: https://lore.kernel.org/r/20200225050828.56458-7-john.stultz@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-04regulator: stm32-vrefbuf: fix a possible overshoot when re-enablingFabrice Gasnier
There maybe an overshoot, when disabling, then re-enabling vrefbuf too quickly. VREFBUF is used by ADC/DAC on some boards. When re-enabling too quickly, an overshoot on the reference voltage make the conversions inaccurate for a short period of time. - Don't put the VREFBUF in HiZ when disabling, to force an active discharge. - Enforce a 1ms OFF/ON delay Fixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Message-Id: <1583312132-20932-1-git-send-email-fabrice.gasnier@st.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-03regulator: anatop: Lower error message level for -EPROBE_DEFERAnson Huang
devm_regulator_register() could return -EPROBE_DEFER when trying to get init data and NOT all resources are available at that time, for this case, error message is better to be present for debug level ONLY. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Link: https://lore.kernel.org/r/1583243052-1930-1-git-send-email-Anson.Huang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02regulator: pwm: Don't warn on probe deferralJon Hunter
Deferred probe is an expected return value for devm_pwm_get(). Given that the driver deals with it properly, rather than warn on probe deferral, only output a message on probe deferral if debug level prints are enabled. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20200302141428.14119-1-jonathanh@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02regulator: anatop: Improve Kconfig dependencyAnson Huang
ANATOP regulator should depend on ARCH_MXC or COMPILE_TEST. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Link: https://lore.kernel.org/r/1583150118-8014-1-git-send-email-Anson.Huang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-26regulator: add smb208 supportAnsuel Smith
Smb208 regulators are used on some ipq806x soc. Add support for it to make it avaiable on some routers that use it. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Signed-off-by: Adrian Panella <ianchi74@outlook.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20200219163711.479-1-ansuelsmth@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-24regulator: axp20x: Fix misleading use of negationOndrej Jirman
It works incidentally, because AXP20X_DCDC2_LDO3_V_RAMP_DCDC2_EN is non-zero, but the false branch value really should be just 0. Signed-off-by: Ondrej Jirman <megous@megous.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20200222235634.243805-1-megous@megous.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-17regulator: mp5416: Fix output discharge enable bit for LDOsAxel Lin
The .active_discharge_on/.active_discharge_mask settings does not match the datasheet, fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20200212150223.20042-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-12regulator: da9062: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20200211234612.GA28682@embeddedor Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-12regulator: da9063: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200211234710.GA29532@embeddedor Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-11regulator: mp5416: add mp5416 regulator driverSaravanan Sekar
Adding regulator driver for the device mp5416. The MP5416 PMIC device contains four DC-DC buck converters and five regulators, accessed over I2C. Signed-off-by: Saravanan Sekar <sravanhome@gmail.com> Link: https://lore.kernel.org/r/20200204110419.25933-3-sravanhome@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-11regulator: da9063: remove redundant return statementRishi Gupta
The devm_request_threaded_irq() already returns 0 on success and negative error code on failure. So return from this itself can be used while preserving error log in case of failure. Signed-off-by: Rishi Gupta <gupt21@gmail.com> Link: https://lore.kernel.org/r/1580996996-28798-1-git-send-email-gupt21@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-11regulator: da9063: fix code formatting warnings and errorsRishi Gupta
This commit fixes following errors & warnings in this driver as reported by checkpatch.pl: - WARNING: Prefer 'unsigned int' to bare use of 'unsigned' - WARNING: line over 80 characters - ERROR: space prohibited before that ',' (ctx:WxW) - ERROR: code indent should use tabs where possible - WARNING: Block comments use * on subsequent lines Signed-off-by: Rishi Gupta <gupt21@gmail.com> Link: https://lore.kernel.org/r/1580996917-28494-1-git-send-email-gupt21@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-11regulator: mp8859: add supply entryMarkus Reichl
Add vin_supply to the regulator description to support a nice regulator tree. Signed-off-by: Markus Reichl <m.reichl@fivetechno.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20200203110034.1448-1-m.reichl@fivetechno.de Signed-off-by: Mark Brown <broonie@kernel.org>