linux-stable.git/drivers/regulator/core.c, branch linux-3.16.y

regulator: fix crash caused by null driver data

2018-12-16T22:09:24+00:00

commit fb6de923ca3358a91525552b4907d4cb38730bdd upstream.

dev_set_drvdata() needs to be called before device_register()
exposes device to userspace. Otherwise kernel crashes after it
gets null pointer from dev_get_drvdata() when userspace tries
to access sysfs entries.

[Removed backtrace for length -- broonie]

Signed-off-by: Yu Zhao 
Signed-off-by: Mark Brown 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

regulator: core: Fix regualtor_ena_gpio_free not to access pin after freeing

2017-07-02T16:13:02+00:00

commit 60a2362f769cf549dc466134efe71c8bf9fbaaba upstream.

After freeing pin from regulator_ena_gpio_free, loop can access
the pin. So this patch fixes not to access pin after freeing.

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Mark Brown 
Signed-off-by: Ben Hutchings

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

Merge remote-tracking branches 'regulator/topic/fixed', 'regulator/topic/id-const', 'regulator/topic/ltc3589', 'regulator/topic/max8649' and 'regulator/topic/of' into regulator-next

2014-06-02T16:08:05+00:00

Merge remote-tracking branch 'regulator/topic/core' into regulator-next

2014-06-02T16:08:02+00:00

regulator: core: Fix the init of DT defined fixed regulators

2014-06-01T18:19:43+00:00

When a regulator is defined using DT and it has a single voltage the
regulator init always tries to apply this voltage. However it fails if
the regulator isn't settable because it is using an internal low level
function. To overcome this we now first query the regulator and only
set it if needed.

Signed-off-by: Alban Bedel 
Signed-off-by: Mark Brown

regulator: core: Disable unused regulators after deferred probing is done

2014-06-01T18:16:12+00:00

regulator_init_complete does a scan of regulators which dont have
always-on or consumers are automatically disabled as being unused.
However, with deferred probing, late_initcall() is too soon to
declare a regulator as unused as the regulator itself might not
have registered due to defferal - Example: A regulator deffered due
to i2bus not available which in turn is deffered due to pinctrl
availability.

Since deferred probing is done in late_initcall(), do the cleanup of
unused regulators by regulator_init_complete in late_initcall_sync
instead of late_initcall.

Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Markus Pargmann 
Signed-off-by: Saravana Kannan 
[nm@ti.com: minor rewording]
Signed-off-by: Nishanth Menon 
Signed-off-by: Mark Brown