summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2015-03-26regulator: core: Fix enable GPIO reference countingDoug Anderson1-14/+12
commit 29d62ec5f87fbeec8413e2215ddad12e7f972e4c upstream. Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list") Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26regulator: Only enable disabled regulators on resumeJavier Martinez Canillas1-3/+5
commit 0548bf4f5ad6fc3bd93c4940fa48078b34609682 upstream. The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-02-06regulator: core: fix race condition in regulator_put()Ashay Jaiswal1-1/+3
commit 83b0302d347a49f951e904184afe57ac3723476e upstream. The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17regulator: arizona-ldo1: remove bypass functionalityNikesh Oswal1-2/+0
commit 5b919f3ebb533cbe400664837e24f66a0836b907 upstream. WM5110/8280 devices do not support bypass mode for LDO1 so remove the bypass callbacks registered with regulator core. Signed-off-by: Nikesh Oswal <nikesh@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-31regulator: core: Replace direct ops->disable usageMarkus Pargmann1-21/+13
commit 66fda75f47dc583f1c187556e9a2c082dd64f8c6 upstream. There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-24regulator: core: Replace direct ops->enable usageMarkus Pargmann1-7/+7
commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream. There are some direct ops->enable in the regulator core driver. This is a potential issue as the function _regulator_do_enable() handles gpio regulators and the normal ops->enable calls. These gpio regulators are simply ignored when ops->enable is called directly. One possible bug is that boot-on and always-on gpio regulators are not enabled on registration. This patch replaces all ops->enable calls by _regulator_do_enable. [Handle missing enable operations -- broonie] Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-24mfd: tps6586x: correct device name of the regulator cellMarc Dietrich1-1/+1
Change the device name of the regulator function to the one chosen for MODULE_ALIAS. This fixes kernel auto-module loading for the regulator function. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2013-05-30Merge remote-tracking branch 'regulator/fix/palmas' into regulator-linusMark Brown1-2/+2
2013-05-30Merge remote-tracking branch 'regulator/fix/doc' into regulator-linusMark Brown1-1/+4
2013-05-30Merge remote-tracking branch 'regulator/fix/dbx500' into regulator-linusMark Brown1-12/+12
2013-05-30regulator: palmas: Fix "enable_reg" to point to the correct reg for SMPS10Kishon Vijay Abraham I1-1/+1
regulator_enable_regmap() uses enable_reg to enable the regulator. But enable_reg for smps10 points to SMPS10_STATUS which is a read-only register. Fixed the same by having enable_reg set to SMPS10_CTRL. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org
2013-05-30regulator: palmas: Fix incorrect conditionSachin Kamat1-1/+1
Since 'id' cannot take two values at the same time, the condition should probably be an OR (||) instead of AND (&&). Introduced by commit 28d1e8cd67 ("regulator: palma: add ramp delay support through regulator constraints"). Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-21regulator: core: Correct spelling mistake in commentCharles Keepax1-1/+1
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-09Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linuxLinus Torvalds1-1/+1
Pull removal of GENERIC_GPIO from Grant Likely: "GENERIC_GPIO now synonymous with GPIOLIB. There are no longer any valid cases for enableing GENERIC_GPIO without GPIOLIB, even though it is possible to do so which has been causing confusion and breakage. This branch does the work to completely eliminate GENERIC_GPIO." * tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux: gpio: update gpio Chinese documentation Remove GENERIC_GPIO config option Convert selectors of GENERIC_GPIO to GPIOLIB blackfin: force use of gpiolib m68k: coldfire: use gpiolib mips: pnx833x: remove requirement for GENERIC_GPIO openrisc: default GENERIC_GPIO to false avr32: default GENERIC_GPIO to false xtensa: remove explicit selection of GENERIC_GPIO sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB powerpc: remove redundant GENERIC_GPIO selection unicore32: default GENERIC_GPIO to false unicore32: remove unneeded select GENERIC_GPIO arm: plat-orion: use GPIO driver on CONFIG_GPIOLIB arm: remove redundant GENERIC_GPIO selection mips: alchemy: require gpiolib mips: txx9: change GENERIC_GPIO to GPIOLIB mips: loongson: use GPIO driver on CONFIG_GPIOLIB mips: remove redundant GENERIC_GPIO select
2013-05-08regulator: dbx500: Make local symbol staticSachin Kamat1-12/+12
power_state_active_get is used only in this file. Make it static. While at it also move this function definition inside the CONFIG_REGULATOR_DEBUG macro as it is called only from within it. This also avoids further build warning related to unused definition. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-05-02regulator: Fix kernel-doc generation warnings.Robert P. J. Day1-1/+4
Add a couple kernel-doc lines to get rid of kernel-doc generation warnings, no functional change. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-28Merge remote-tracking branch 'regulator/topic/wm8994' into v3.9-rc8Mark Brown1-19/+42
2013-04-28Merge remote-tracking branch 'regulator/topic/twl' into v3.9-rc8Mark Brown1-31/+3
2013-04-28Merge remote-tracking branch 'regulator/topic/tps80031' into v3.9-rc8Mark Brown1-21/+24
2013-04-28Merge remote-tracking branch 'regulator/topic/tps6586x' into v3.9-rc8Mark Brown1-4/+2
2013-04-28Merge remote-tracking branch 'regulator/topic/tps65023' into v3.9-rc8Mark Brown1-22/+9
2013-04-28Merge remote-tracking branch 'regulator/topic/tps62360' into v3.9-rc8Mark Brown1-1/+1
2013-04-28Merge remote-tracking branch 'regulator/topic/s5m8767' into v3.9-rc8Mark Brown1-1/+1
2013-04-28Merge remote-tracking branch 'regulator/topic/rc5t583' into v3.9-rc8Mark Brown1-6/+0
2013-04-28Merge remote-tracking branch 'regulator/topic/palmas' into v3.9-rc8Mark Brown1-60/+305
2013-04-28Merge remote-tracking branch 'regulator/topic/max8998' into v3.9-rc8Mark Brown1-3/+6
2013-04-28Merge remote-tracking branch 'regulator/topic/max8997' into v3.9-rc8Mark Brown1-2/+2
2013-04-28Merge remote-tracking branch 'regulator/topic/max8973' into v3.9-rc8Mark Brown1-5/+5
2013-04-28Merge remote-tracking branch 'regulator/topic/max8952' into v3.9-rc8Mark Brown1-2/+73
2013-04-28Merge remote-tracking branch 'regulator/topic/max8925' into v3.9-rc8Mark Brown1-3/+2
2013-04-28Merge remote-tracking branch 'regulator/topic/max77686' into v3.9-rc8Mark Brown1-11/+21
2013-04-28Merge remote-tracking branch 'regulator/topic/max1586' into v3.9-rc8Mark Brown1-1/+1
2013-04-28Merge remote-tracking branch 'regulator/topic/lp8788' into v3.9-rc8Mark Brown1-48/+11
2013-04-28Merge remote-tracking branch 'regulator/topic/gpio' into v3.9-rc8Mark Brown2-100/+140
2013-04-28Merge remote-tracking branch 'regulator/topic/fan53555' into v3.9-rc8Mark Brown1-3/+1
2013-04-28Merge remote-tracking branch 'regulator/topic/enable-invert' into v3.9-rc8Mark Brown3-69/+30
2013-04-28Merge remote-tracking branch 'regulator/topic/core' into v3.9-rc8Mark Brown6-17/+27
2013-04-28Merge remote-tracking branch 'regulator/topic/ascend' into v3.9-rc8Mark Brown11-10/+55
2013-04-28Merge remote-tracking branch 'regulator/topic/as3711' into v3.9-rc8Mark Brown1-3/+64
2013-04-28Merge remote-tracking branch 'regulator/topic/arizona' into v3.9-rc8Mark Brown1-1/+1
2013-04-28Merge remote-tracking branch 'regulator/topic/ab8500' into v3.9-rc8Mark Brown4-148/+2925
2013-04-28Merge remote-tracking branch 'regulator/topic/ab3100' into v3.9-rc8Mark Brown1-50/+186
2013-04-28regulator: mc13892: Fix MC13892_SWITCHERS0_SWxHI bit in set_voltage_selAxel Lin1-3/+3
It is necessary to clear MC13892_SWITCHERS0_SWxHI bit when set voltage to the voltage range from 1100000 to 1375000. Leaving MC13892_SWITCHERS0_SWxHI bit untouched may result in wrong voltage setting. For example, currently switch voltage from 1400000 to 1300000 will set the voltage to 1800000 because the HI bit is still set. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@sirena.org.uk>
2013-04-28regulator: Remove NULL test before calling regulator_unregister()Axel Lin5-14/+7
It's safe to call regulator_unregister() with NULL, thus remove the NULL test before regulator_unregister() calls. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@sirena.org.uk>
2013-04-28regulator: mc13783: Add device tree probe supportAlexander Shiyan1-15/+29
Patch adds device tree probe support for mc13783-regulator driver. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Mark Brown <broonie@sirena.org.uk>
2013-04-28regulator: mc13xxx: Add warning of incorrect names of regulatorsAlexander Shiyan3-43/+17
This patch adds a warning about incorrect regulators instead of printing the names of non-information message about the wrong amount. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Mark Brown <broonie@sirena.org.uk>
2013-04-28regulator: max77686: Don't update max77686->opmode if update register failsAxel Lin1-11/+21
Ensure max77686->opmode always has correct status. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@sirena.org.uk>
2013-04-26regulator: max8952: Add missing config.of_node setting for regulator registerAxel Lin1-0/+1
Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-26regulator: ab3100: Fix regulator register error handlingAxel Lin1-14/+19
Ensure to unregister all regulators before return error in probe(). The regulator register order depends on the regulator ID pass to ab3100_regulator_register() function. Thus we need to scan ab3100_regulator_desc and find the index of successfully registered regulators, or alternatively just call ab3100_regulators_remove() to unregister all registered regulators. Since current code uses a static ab3100_regulators table, explicitly set reg->rdev = NULL after regulator_unregister() call to ensure calling ab3100_regulators_remove() in the unwind path always work. Also move ab3100_regulators_remove() to avoid forward declaration. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-26regulator: tps6524x: Use regulator_map_voltage_ascendAxel Lin1-0/+1
All regulators have ascendant voltage list in this driver. Use regulator_map_voltage_ascend for them. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>