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

regulator: Fix deadlock during regulator registration

2016-06-08T01:23:43+00:00

commit a2151374230820a3a6e654f2998b2a44dbfae4e1 upstream.

Commit 5e3ca2b349b1 ("regulator: Try to resolve regulators supplies on
registration") added a call to regulator_resolve_supply() within
regulator_register() where the regulator_list_mutex is held. This causes
a deadlock to occur on the Tegra114 Dalmore board when the palmas PMIC
is registered because regulator_register_resolve_supply() calls
regulator_dev_lookup() which may try to acquire the regulator_list_mutex
again.

Fix this by releasing the mutex before calling
regulator_register_resolve_supply() and update the error exit path to
ensure the mutex is released on an error.

[Made commit message more legible -- broonie]

Signed-off-by: Jon Hunter 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: Try to resolve regulators supplies on registration

2016-06-08T01:23:37+00:00

commit 5e3ca2b349b1e2c80b060b51bbf2af37448fad85 upstream.

Commit 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
moved the regulator supplies lookup logic from the regulators registration
to the regulators get time.

Unfortunately, that changed the behavior of the regulator core since now a
parent supply with a child regulator marked as always-on, won't be enabled
unless a client driver attempts to get the child regulator during boot.

This patch tries to resolve the parent supply for the already registered
regulators each time that a new regulator is registered. So the regulators
that have child regulators marked as always on will be enabled regardless
if a driver gets the child regulator or not.

That was the behavior before the mentioned commit, since parent supplies
were looked up at regulator registration time instead of during child get.

Since regulator_resolve_supply() checks for rdev->supply, most of the times
it will be a no-op. Errors aren't checked to keep the possible out of order
dependencies which was the motivation for the mentioned commit.

Also, the supply being available will be enforced on regulator get anyways
in case the resolve fails on regulators registration.

Fixes: 6261b06de565 ("regulator: Defer lookup of supply to regulator_get")
Suggested-by: Mark Brown 
Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

Merge remote-tracking branches 'regulator/topic/ltc3589', 'regulator/topic/max77620', 'regulator/topic/max77686', 'regulator/topic/max77802' and 'regulator/topic/maxim' into regulator-next

2016-03-13T08:19:47+00:00

Merge remote-tracking branches 'regulator/topic/discharge', 'regulator/topic/fan53555', 'regulator/topic/gpio', 'regulator/topic/hi655x' and 'regulator/topic/lp872x' into regulator-next

2016-03-13T08:19:35+00:00

regulator: core: Add support for active-discharge configuration

2016-03-02T14:31:45+00:00

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

regulator: core: Add support for active-discharge configuration

2016-03-02T14:13:05+00:00

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

regulator: core: fix crash in error path of regulator_register

2016-02-25T01:48:16+00:00

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
[] (__dabt_svc) from [] (kernfs_find_ns+0x18/0xf8)
[] (kernfs_find_ns) from [] (kernfs_find_and_get_ns+0x40/0x58)
[] (kernfs_find_and_get_ns) from [] (sysfs_unmerge_group+0x28/0x68)
[] (sysfs_unmerge_group) from [] (dpm_sysfs_remove+0x30/0x5c)
[] (dpm_sysfs_remove) from [] (device_del+0x48/0x1f4)
[] (device_del) from [] (device_unregister+0x30/0x6c)
[] (device_unregister) from [] (regulator_register+0x6d0/0xdac)
[] (regulator_register) from [] (devm_regulator_register+0x50/0x84)
[] (devm_regulator_register) from [] (reg_fixed_voltage_probe+0x25c/0x3c0)
[] (reg_fixed_voltage_probe) from [] (platform_drv_probe+0x60/0xb0)
[] (platform_drv_probe) from [] (driver_probe_device+0x24c/0x440)
[] (driver_probe_device) from [] (__device_attach_driver+0xc0/0x120)
[] (__device_attach_driver) from [] (bus_for_each_drv+0x6c/0x98)
[] (bus_for_each_drv) from [] (__device_attach+0xac/0x138)
[] (__device_attach) from [] (device_initial_probe+0x1c/0x20)
[] (device_initial_probe) from [] (bus_probe_device+0x94/0x9c)
[] (bus_probe_device) from [] (deferred_probe_work_func+0x80/0xcc)
[] (deferred_probe_work_func) from [] (process_one_work+0x158/0x454)
[] (process_one_work) from [] (worker_thread+0x38/0x510)
[] (worker_thread) from [] (kthread+0xe8/0x104)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)

Signed-off-by: Krzysztof Adamski 
Reported-by: Jon Hunter 
Acked-by: Jon Hunter 
Tested-by: Jon Hunter 
Signed-off-by: Mark Brown

Merge branch 'fix/core' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core

2016-02-25T01:48:11+00:00

regulator: core: Request GPIO before creating sysfs entries

2016-02-22T10:51:05+00:00

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

regulator: core: Rely on regulator_dev_release to free constraints

2016-01-27T14:41:42+00:00

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