linux-stable.git/drivers/regulator, branch v3.12.64

regulator: core: fix constraints output buffer

2015-07-30T12:10:50+00:00

commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream.

The buffer for condtraints debug isn't big enough to hold the output
in all cases. So fix this issue by increasing the buffer.

Signed-off-by: Stefan Wahren 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: core: Fix enable GPIO reference counting

2015-04-09T11:14:13+00:00

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 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: Only enable disabled regulators on resume

2015-04-09T11:14:12+00:00

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 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: core: fix race condition in regulator_put()

2015-02-08T19:02:03+00:00

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 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: max77693: Fix use of uninitialized regulator config

2014-11-13T18:03:07+00:00

commit ca0c37a0b489bb14bf3e1549e7a8d0c9a17f4919 upstream.

Driver allocated on stack struct regulator_config but didn't initialize
it fully. Few fields (driver_data, ena_gpio) were left untouched. This
lead to using random ena_gpio values as GPIOs for max77693 regulators.

On occasion these values could match real GPIO numbers leading to
interfering with other drivers and to unsuccessful enable/disable of
regulator.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: arizona-ldo1: remove bypass functionality

2014-09-17T14:55:03+00:00

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 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: arizona-ldo1: Correct default regulator init_data

2014-05-15T07:55:02+00:00

commit a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 upstream.

Both 5102 and 8997 have the regulator capable of supplying 1.8V, and the
voltage step from the 5110 regulator is different from what is specified
in the default description. This patch updates the default regulator
description to match 5110 and selects the 1.8V capable description for
8997.

Signed-off-by: Charles Keepax 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: core: Replace direct ops->disable usage

2014-03-31T12:22:31+00:00

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 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: core: Replace direct ops->enable usage

2014-03-22T21:01:53+00:00

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 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby

regulator: da9063: Bug fix when setting max voltage on LDOs 5-11

2014-03-05T16:13:50+00:00

commit ebf6dad0de89677aa58a4d8b009014ff88a23452 upstream.

Bug fix to allow the setting of maximum voltage for certain LDOs.

What the bug is:

There is a problem caused by an invalid calculation of n_voltages
in the driver. This n_voltages value has the potential to be
different for each regulator.

The value for linear_min_sel is set as DA9063_V##regl_name#
which can be different depending upon the regulator. This is
chosen according to the following definitions in the DA9063
registers.h file:

DA9063_VLDO1_BIAS	0
DA9063_VLDO2_BIAS	0
DA9063_VLDO3_BIAS	0
DA9063_VLDO4_BIAS	0
DA9063_VLDO5_BIAS	2
DA9063_VLDO6_BIAS	2
DA9063_VLDO7_BIAS	2
DA9063_VLDO8_BIAS	2
DA9063_VLDO9_BIAS	3
DA9063_VLDO10_BIAS	2
DA9063_VLDO11_BIAS	2

The calculation for n_voltages is valid for LDOs whose BIAS value
is zero but this is not correct for those LDOs which have a
non-zero value.

What the fix is:

In order to take into account the non-zero linear_min_sel value which
is set for the regulators LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 and
LDO11, the calculation for n_voltages should take into account the
missing term defined by DA9063_V##regl_name#.

This will in turn allow the core constraints calculation to set the
maximum voltage limits correctly and therefore allow users to apply
the maximum expected voltage to all of the LDOs.

Signed-off-by: Steve Twiss 
Signed-off-by: Mark Brown 
Signed-off-by: Jiri Slaby