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

regulator: s5m8767: fix get_register() error handling

2016-04-30T22:05:48+00:00

commit e07ff9434167981c993a26d2edbbcb8e13801dbb upstream.

The s5m8767_pmic_probe() function calls s5m8767_get_register() to
read data without checking the return code, which produces a compile-time
warning when that data is accessed:

drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes the s5m8767_get_register() function to return a -EINVAL
not just for an invalid register number but also for an invalid
regulator number, as both would result in returning uninitialized
data. The s5m8767_pmic_probe() function is then changed accordingly
to fail on a read error, as all the other callers of s5m8767_get_register()
already do.

In practice this probably cannot happen, as we don't call
s5m8767_get_register() with invalid arguments, but the gcc
warning seems valid in principle, in terms writing safe
error checking.

Signed-off-by: Arnd Bergmann 
Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

regulator: pbias: Fix broken pbias disable functionality

2015-09-28T09:21:40+00:00

commit c329061be51bef655f28c9296093984c977aff85 upstream.

regulator_disable of pbias always writes '0' to the enable_reg.
However actual disable value of pbias regulator is not always '0'.
Fix it by populating the disable_val in pbias_reg_info for the
various platforms and assign it to the disable_val of
pbias regulator descriptor. This will be used by
regulator_disable_regmap while disabling pbias regulator.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques

regulator: core: fix constraints output buffer

2015-07-15T09:00:25+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: Luis Henriques

regulator: core: Fix enable GPIO reference counting

2015-03-30T10:11:07+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: Luis Henriques

regulator: Only enable disabled regulators on resume

2015-03-30T10:11:06+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: Luis Henriques

regulator: core: fix race condition in regulator_put()

2015-02-04T10:58:01+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: Luis Henriques

regulator: anatop: Set default voltage selector for vddpu

2015-01-05T13:33:40+00:00

commit fe08be3ec8672ed92b3ed1b85810df9fa0f98931 upstream.

The code reads the default voltage selector from its register. If the
bootloader disables the regulator, the default voltage selector will be
0 which results in faulty behaviour of this regulator driver.

This patch sets a default voltage selector for vddpu if it is not set in
the register.

Signed-off-by: Markus Pargmann 
Signed-off-by: Mark Brown 
Signed-off-by: Luis Henriques

regulator: max77693: Fix use of uninitialized regulator config

2014-11-14T15:19:55+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: Luis Henriques

regulator: ltc3589: fix broken voltage transitions

2014-10-30T16:40:12+00:00

commit c5bb725ac2d1a13e9e766bf9a16bac986ade17cd upstream.

VCCR is used as a trigger to start voltage transitions, so
we need to mark it volatile in order to make sure it gets
written to hardware every time we set a new voltage.

Fixes regulator voltage being stuck at the first voltage
set after driver load.

[lst: reworded commit message]
Signed-off-by: Steffen Trumtrar 
Signed-off-by: Lucas Stach 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: tps65218: fix DCDC4 linear voltage range

2014-09-17T16:21:55+00:00

commit 42ab0f3915f22728f54bb1f3c0dcf38ab2335b5b upstream.

The second range of this particular regulator,
starts at 1.60V, not as 1.55V as it was originally
implied by code.

Signed-off-by: Felipe Balbi 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman