summaryrefslogtreecommitdiff
path: root/drivers/regulator/core.c
AgeCommit message (Collapse)Author
2016-03-13Merge remote-tracking branches 'regulator/topic/ltc3589', ↵Mark Brown
'regulator/topic/max77620', 'regulator/topic/max77686', 'regulator/topic/max77802' and 'regulator/topic/maxim' into regulator-next
2016-03-13Merge remote-tracking branches 'regulator/topic/discharge', ↵Mark Brown
'regulator/topic/fan53555', 'regulator/topic/gpio', 'regulator/topic/hi655x' and 'regulator/topic/lp872x' into regulator-next
2016-03-02regulator: core: Add support for active-discharge configurationLaxman Dewangan
Add support to enable/disable active discharge of regulator via machine constraints. This configuration is done when setting machine constraint during regulator register and if regulator driver implemented the callback ops. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-02regulator: core: Add support for active-discharge configurationLaxman Dewangan
Add support to enable/disable active discharge of regulator via machine constraints. This configuration is done when setting machine constraint during regulator register and if regulator driver implemented the callback ops. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-25regulator: core: fix crash in error path of regulator_registerKrzysztof Adamski
This problem was introduced by: commit daad134d6649 ("regulator: core: Request GPIO before creating sysfs entries") The error path was not updated correctly after moving GPIO registration code and in case regulator_ena_gpio_free failed, device_unregister() was called even though device_register() was not yet called. This problem breaks the boot at least on all Tegra 32-bit devices. It will also crash each device that specifices GPIO that is unavaiable at regulator_register call. Here's error log I've got when forced GPIO to be invalid: [ 1.116612] usb-otg-vbus-reg: Failed to request enable GPIO10: -22 [ 1.122794] Unable to handle kernel NULL pointer dereference at virtual address 00000044 [ 1.130894] pgd = c0004000 [ 1.133598] [00000044] *pgd=00000000 [ 1.137205] Internal error: Oops: 5 [#1] SMP ARM and here's backtrace from KDB: Exception stack(0xef11fbd0 to 0xef11fc18) fbc0: 00000000 c0738a14 00000000 00000000 fbe0: c0b2a0b0 00000000 00000000 c0738a14 c0b5fdf8 00000001 ef7f6074 ef11fc4c fc00: ef11fc50 ef11fc20 c02a8344 c02a7f1c 60000013 ffffffff [<c010cee0>] (__dabt_svc) from [<c02a7f1c>] (kernfs_find_ns+0x18/0xf8) [<c02a7f1c>] (kernfs_find_ns) from [<c02a8344>] (kernfs_find_and_get_ns+0x40/0x58) [<c02a8344>] (kernfs_find_and_get_ns) from [<c02ac4a4>] (sysfs_unmerge_group+0x28/0x68) [<c02ac4a4>] (sysfs_unmerge_group) from [<c044389c>] (dpm_sysfs_remove+0x30/0x5c) [<c044389c>] (dpm_sysfs_remove) from [<c0436ba8>] (device_del+0x48/0x1f4) [<c0436ba8>] (device_del) from [<c0436d84>] (device_unregister+0x30/0x6c) [<c0436d84>] (device_unregister) from [<c0403910>] (regulator_register+0x6d0/0xdac) [<c0403910>] (regulator_register) from [<c04052d4>] (devm_regulator_register+0x50/0x84) [<c04052d4>] (devm_regulator_register) from [<c0406298>] (reg_fixed_voltage_probe+0x25c/0x3c0) [<c0406298>] (reg_fixed_voltage_probe) from [<c043d21c>] (platform_drv_probe+0x60/0xb0) [<c043d21c>] (platform_drv_probe) from [<c043b078>] (driver_probe_device+0x24c/0x440) [<c043b078>] (driver_probe_device) from [<c043b5e8>] (__device_attach_driver+0xc0/0x120) [<c043b5e8>] (__device_attach_driver) from [<c043901c>] (bus_for_each_drv+0x6c/0x98) [<c043901c>] (bus_for_each_drv) from [<c043ad20>] (__device_attach+0xac/0x138) [<c043ad20>] (__device_attach) from [<c043b664>] (device_initial_probe+0x1c/0x20) [<c043b664>] (device_initial_probe) from [<c043a074>] (bus_probe_device+0x94/0x9c) [<c043a074>] (bus_probe_device) from [<c043a610>] (deferred_probe_work_func+0x80/0xcc) [<c043a610>] (deferred_probe_work_func) from [<c01381d0>] (process_one_work+0x158/0x454) [<c01381d0>] (process_one_work) from [<c013854c>] (worker_thread+0x38/0x510) [<c013854c>] (worker_thread) from [<c013e154>] (kthread+0xe8/0x104) [<c013e154>] (kthread) from [<c0108638>] (ret_from_fork+0x14/0x3c) Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com> Reported-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-25Merge branch 'fix/core' of ↵Mark Brown
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core
2016-02-22regulator: core: Request GPIO before creating sysfs entriesKrzysztof Adamski
regulator_attr_is_visible (which is a .is_visible callback of regulator_dev_group attribute_grpup) checks rdev->ena_pin to decide if "status" file should be present in sysfs. This field is set at the end of regulator_ena_gpio_request so it has to be called before device_register() otherwise this test will always fail, causing "status" file to not be visible. Since regulator_attr_is_visible also tests for is_enabled() op, this problem is only visible for regulators that does not define this callback, like regulator-fixed.c. Signed-off-by: Krzysztof Adamski <krzysztof.adamski@tieto.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-27regulator: core: Rely on regulator_dev_release to free constraintsCharles Keepax
As we now free the constraints in regulator_dev_release we will still call free on the constraints pointer even if we went down an error path in regulator_register, because it is only allocated after the device_register. As such we no longer need to free rdev->constraints on the error paths, so this patch removes said frees. Fixes: 29f5f4860a8e ("regulator: core: Move more deallocation into class unregister") Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-12Merge remote-tracking branches 'regulator/topic/lp8788', ↵Mark Brown
'regulator/topic/mt6311', 'regulator/topic/optional', 'regulator/topic/palmas' and 'regulator/topic/pv88060' into regulator-next
2016-01-12Merge remote-tracking branches 'regulator/topic/const', ↵Mark Brown
'regulator/topic/lm363x', 'regulator/topic/lockdep' and 'regulator/topic/lp872x' into regulator-next
2016-01-12Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2016-01-07regulator: core: remove some dead codeDan Carpenter
Originally queue_delayed_work() used to negative error codes or 0 and 1 on success depending if the work was queued or not. It caused a lot of bugs where people treated all non-zero returns as failures so we changed it to return bool instead in d4283e937861 ('workqueue: make queueing functions return bool'). Now it never returns failure. Checking for negative values causes a static checker warning since it is impossible based on the bool type. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-05regulator: core: use dev_to_rdevGeliang Tang
Use dev_to_rdev() instead of open-coding it. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-12-02regulator: core: Fix nested locking of suppliesThierry Reding
Commit fa731ac7ea04 ("regulator: core: avoid unused variable warning") introduced a subtle change in how supplies are locked. Where previously code was always locking the regulator of the current iteration, the new implementation only locks the regulator if it has a supply. For any given power tree that means that the root will never get locked. On the other hand the regulator_unlock_supply() will still release all the locks, which in turn causes the lock debugging code to warn about a mutex being unlocked which wasn't locked. Cc: Mark Brown <broonie@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Fixes: Fixes: fa731ac7ea04 ("regulator: core: avoid unused variable warning") Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-12-02regulator: core: Ensure we lock all regulatorsMark Brown
The latest workaround for the lockdep interface's not using the second argument of mutex_lock_nested() changed the loop missed locking the last regulator due to a thinko with the loop termination condition exiting one regulator too soon. Reported-by: Tyler Baker <tyler.baker@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-27regulator: core: fix regulator_lock_supply regressionArnd Bergmann
As noticed by Geert Uytterhoeven, my patch to avoid a harmless build warning in regulator_lock_supply() was total crap and introduced a real bug: > [ BUG: bad unlock balance detected! ] > kworker/u4:0/6 is trying to release lock (&rdev->mutex) at: > [<c0247b84>] regulator_set_voltage+0x38/0x50 we still lock the regulator supplies, but not the actual regulators, so we are missing a lock, and the unlock is unbalanced. This rectifies it by first locking the regulator device itself before using the same loop as before to lock its supplies. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 716fec9d1965 ("[SUBMITTED] regulator: core: avoid unused variable warning") Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-20regulator: core: avoid unused variable warningArnd Bergmann
The second argument of the mutex_lock_nested() helper is only evaluated if CONFIG_DEBUG_LOCK_ALLOC is set. Otherwise we get this build warning for the new regulator_lock_supply function: drivers/regulator/core.c: In function 'regulator_lock_supply': drivers/regulator/core.c:142:6: warning: unused variable 'i' [-Wunused-variable] To avoid the warning, this restructures the code to make it both simpler and to move the 'i++' outside of the mutex_lock_nested call, where it is now always used and the variable is not flagged as unused. We had some discussion about changing mutex_lock_nested to an inline function, which would make the code do the right thing here, but in the end decided against it, in order to guarantee that mutex_lock_nested() does not introduced overhead without CONFIG_DEBUG_LOCK_ALLOC. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9f01cd4a915 ("regulator: core: introduce function to lock regulators and its supplies") Link: http://permalink.gmane.org/gmane.linux.kernel/2068900 Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-17regulator: Make bulk API support optional suppliesBjorn Andersson
Make it possible to use the bulk API with optional supplies, by allowing the consumer to marking supplies as optional in the regulator_bulk_data. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-04Merge remote-tracking branches 'regulator/topic/supply', ↵Mark Brown
'regulator/topic/tps6105x' and 'regulator/topic/tps65023' into regulator-next
2015-11-04Merge remote-tracking branch 'regulator/topic/list' into regulator-nextMark Brown
2015-11-04Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2015-11-04regulator: Use regulator_lock_supply() for get_voltage() tooMark Brown
Since we need to read voltages of parents as part of setting supply voltages we need to be able to do get_voltage() internally without taking locks so reorganize the locking to take locks on the full tree on entry rather than as we recurse when called externally. Reported-by: John Stultz <john.stultz@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-22regulator: core: Propagate voltage changes to supply regulatorsSascha Hauer
Until now changing the voltage of a regulator only ever effected the regulator itself, but never its supplies. It's a common pattern though to put LDO regulators behind switching regulators. The switching regulators efficiently drop the input voltage but have a high ripple on their output. The output is then cleaned up by the LDOs. For higher energy efficiency the voltage drop at the LDOs should be minimized. For this scenario we need to propagate the voltage change to the supply regulators. Another scenario where voltage propagation is desired is a regulator which only consists of a switch and thus cannot regulate voltages itself. In this case we can pass setting voltages to the supply. This patch adds support for voltage propagation. We do voltage propagation when the current regulator has a minimum dropout voltage specified or if the current regulator lacks a get_voltage operation (indicating it's a switch and not a regulator). Changing the supply voltage must be done carefully. When we are increasing the current regulators output we must first increase the supply voltage and then the regulator itself. When we are decreasing the current regulators voltage we must decrease the supply voltage after changing the current regulators voltage. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-20regulator: core: Factor out regulator_map_voltageSascha Hauer
_regulator_call_set_voltage has code to translate a minimum/maximum voltage pair into a selector. This code is useful for others aswell, so create a regulator_map_voltage function. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-16regulator: core: create unlocked version of regulator_set_voltageSascha Hauer
The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-01regulator: core: create unlocked version of regulator_list_voltageSascha Hauer
The unlocked version will be needed when we start propagating voltage changes to the supply regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-01regulator: core: introduce function to lock regulators and its suppliesSascha Hauer
Each regulator_dev is locked with its own mutex. This is fine as long as only one regulator_dev is locked, but makes lockdep unhappy when we have to walk up the supply chain like it can happen in regulator_get_voltage: regulator_get_voltage -> mutex_lock(&regulator->rdev->mutex) -> _regulator_get_voltage(regulator->rdev) -> regulator_get_voltage(rdev->supply) -> mutex_lock(&regulator->rdev->mutex); This causes lockdep to issue a possible deadlock warning. There are at least two ways to work around this: - We can always lock the whole supply chain using the functions introduced with this patch. - We could store the current voltage in struct regulator_rdev so that we do not have to walk up the supply chain for the _regulator_get_voltage case. Anyway, regulator_lock_supply/regulator_unlock_supply will be needed once we allow regulator_set_voltage to optimize the supply voltages. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-01regulator: core: Handle probe deferral from DT when resolving suppliesMark Brown
When resolving regulator-regulator supplies we ignore probe deferral returns from regulator_dev_lookup() (such as are generated for DT when we can see a supply is registered) and just fall back to the dummy regulator if there are full constraints (as is the case for DT). This means that probe deferral is broken for DT systems, fix that by paying attention to -EPROBE_DEFER return codes like we do -ENODEV. A further patch will simplify this further, this is a minimal fix for the specific issue. Fixes: 9f7e25edb1575a6d2 (regulator: core: Handle full constraints systems when resolving supplies) Reported-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Mark Brown <broonnie@kernel.org> Cc: stable@vger.kernel.org
2015-09-21Merge remote-tracking branch 'regulator/fix/core' into regulator-linusMark Brown
2015-09-21regulator: core: Remove regulator_listTomeu Vizoso
As we are already registering a device with regulator_class for each regulator device, regulator_list is redundant and can be replaced with calls to class_find_device() and class_for_each_device(). Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-17regulator: core: Correct return value check in regulator_resolve_supplyCharles Keepax
The ret pointer passed to regulator_dev_lookup is only filled with a valid error code if regulator_dev_lookup returned NULL. Currently regulator_resolve_supply checks this ret value before it checks if a regulator was returned, this can result in valid regulator lookups being ignored. Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get") Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-09-16regulator: core: Make error messages more informativeStephen Boyd
The same error print exists 4 times in the regulator core <rdev>: operation not allowed Unfortunately, seeing this in the dmesg is not very informative. Add what type of operation is not allowed to the message so that these errors are unique, hopefully pointing developers in the right direction <rdev>: drms operation not allowed <rdev>: voltage operation not allowed <rdev>: current operation not allowed <rdev>: mode operation not allowed Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-08Merge tag 'regmap-v4.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap updates from Mark Brown: "This has been a busy release for regmap. By far the biggest set of changes here are those from Markus Pargmann which implement support for block transfers in smbus devices. This required quite a bit of refactoring but leaves us better able to handle odd restrictions that controllers may have and with better performance on smbus. Other new features include: - Fix interactions with lockdep for nested regmaps (eg, when a device using regmap is connected to a bus where the bus controller has a separate regmap). Lockdep's default class identification is too crude to work without help. - Support for must write bitfield operations, useful for operations which require writing a bit to trigger them from Kuniori Morimoto. - Support for delaying during register patch application from Nariman Poushin. - Support for overriding cache state via the debugfs implementation from Richard Fitzgerald" * tag 'regmap-v4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: (25 commits) regmap: fix a NULL pointer dereference in __regmap_init regmap: Support bulk reads for devices without raw formatting regmap-i2c: Add smbus i2c block support regmap: Add raw_write/read checks for max_raw_write/read sizes regmap: regmap max_raw_read/write getter functions regmap: Introduce max_raw_read/write for regmap_bulk_read/write regmap: Add missing comments about struct regmap_bus regmap: No multi_write support if bus->write does not exist regmap: Split use_single_rw internally into use_single_read/write regmap: Fix regmap_bulk_write for bus writes regmap: regmap_raw_read return error on !bus->read regulator: core: Print at debug level on debugfs creation failure regmap: Fix regmap_can_raw_write check regmap: fix typos in regmap.c regmap: Fix integertypes for register address and value regmap: Move documentation to regmap.h regmap: Use different lockdep class for each regmap init call thermal: sti: Add parentheses around bridge->ops->regmap_init call mfd: vexpress: Add parentheses around bridge->ops->regmap_init call regmap: debugfs: Fix misuse of IS_ENABLED ...
2015-09-04Merge remote-tracking branches 'regmap/topic/debugfs' and ↵Mark Brown
'regmap/topic/force-update' into regmap-next
2015-09-02regulator: core: fix possible NULL dereferenceSudip Mukherjee
We were checking rdev->supply for NULL after dereferencing it. Lets check for rdev->supply along with _regulator_is_enabled() and call regulator_enable() only if rdev->supply is not NULL. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-30Merge remote-tracking branches 'regulator/topic/mt6311', ↵Mark Brown
'regulator/topic/ocp', 'regulator/topic/owner', 'regulator/topic/pfuze100' and 'regulator/topic/pwm' into regulator-next
2015-08-30Merge remote-tracking branches 'regulator/topic/da9210', ↵Mark Brown
'regulator/topic/da9211', 'regulator/topic/fan53555', 'regulator/topic/isl9305' and 'regulator/topic/list' into regulator-next
2015-08-30Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2015-08-28regulator: core: use debug level print in regulator_check_drmsArchit Taneja
When calling regulator_set_load, regulator_check_drms prints and returns an error if the regulator device's flag REGULATOR_CHANGE_DRMS isn't set. drms_uA_update, however, bails out without reporting an error. Replace the error print with a debug level print so that we don't get such prints when the underlying regulator doesn't support DRMS. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-17regulator: core: Use IS_ERR_OR_NULL()Viresh Kumar
Use IS_ERR_OR_NULL() rather than open coding it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-14regulator: core: Print at debug level on debugfs creation failureStephen Boyd
Failure to create a debugfs node is not an error, but we print a warning upon failure to create the node. Downgrade this to a debug printk so that we're quiet here. This allows multiple drivers to request a CPU's regulator so that CPUfreq and AVSish drivers can coexist. The downside of this approach is that whoever gets to debugfs first the others who come later to not have any debugfs attributes associated with them. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-13regulator: core: Spelling fixViresh Kumar
Trivial spell fix, s/succesfully/successfully. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12regulator: core: Use class device list for regulator_list in late initMark Brown
The regulator_list has exactly the same contents as the list that the driver core maintains of regulator_class members so is redundant. As a first step in converting over to use the class device list convert our iteration in late_initcall() to use the class device iterator. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12regulator: core: Move more deallocation into class unregisterMark Brown
We really ought to be using the class dvice lifetime management features more than we are rather than open coding them so take a step towards that by moving some of the simplest deallocations to the dev_release() function. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-12regulator: core: Reduce rdev locking region when releasing regulatorMark Brown
When we release a regulator we need to remove references to it from the rdev which means locking the rdev. Currently we also free resources associated with the regulator inside the rdev lock but there is no need to do this, we can reduce the region the lock is held by restricting it to just actions that affect the rdev. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-07regulator: core: Drop regulator_list_mutex when we're done with it on removeMark Brown
When removing a regulator we hold regulator_list_mutex in order to ensure the regualtor doesn't become removed again. However we only need to protect the list until we remove the regulator from the list so move the unlock earlier to reduce the locked region. Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-24regulator: Add over current protection (OCP) supportStephen Boyd
Some regulators can automatically shut down when they detect an over current event. Add an op (set_over_current_protection) and a DT property + constraint to support this capability. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-24Merge remote-tracking branches 'regulator/fix/88pm800', ↵Mark Brown
'regulator/fix/max8973', 'regulator/fix/s2mps11' and 'regulator/fix/supply' into regulator-linus
2015-07-16regulator: core: Fix memory leak in regulator_resolve_supply()Javier Martinez Canillas
The regulator_resolve_supply() function calls set_supply() which in turn calls create_regulator() to allocate a supply regulator. If an error occurs after set_supply() succeeded, the allocated regulator has to be freed before propagating the error code. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-16regulator: core: Increase refcount for regulator supply's moduleJavier Martinez Canillas
When a regulator is unregistered with regulator_unregister(), a call to regulator_put() is made for its input supply if there is one. This does a module_put() to decrement the refcount of the module that owns the supply but there isn't a corresponding try_module_get() in set_supply() to make the calls balanced. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>