linux-stable.git/drivers/regulator, branch v4.1.41

regulator: tps65023: Fix inverted core enable logic.

2017-05-17T19:08:23+00:00

[ Upstream commit c90722b54a4f5e21ac59301ed9a6dbaa439bdb16 ]

Commit 43530b69d758328d3ffe6ab98fd640463e8e3667 ("regulator: Use
regmap_read/write(), regmap_update_bits functions directly") intended
to replace working inline helper functions with standard regmap
calls.  However, it also inverted the set/clear logic of the "CORE ADJ
Allowed" bit.  That patch was clearly never tested, since without that
bit cleared, the core VDCDC1 voltage output does not react to I2C
configuration changes.

This patch fixes the issue by clearing the bit as in the original,
correct implementation.  Note for stable back porting that, due to
subsequent driver churn, this patch will not apply on every kernel
version.

Fixes: 43530b69d758 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly")
Signed-off-by: Richard Cochran 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

regulator: Fix regulator_summary for deviceless consumers

2017-05-17T19:06:59+00:00

[ Upstream commit e42a46b6f52473661ad192f76a128a68fe301df4 ]

It is allowed to call regulator_get with a NULL dev argument
(_regulator_get explicitly checks for it) but this causes an error later
when printing /sys/kernel/debug/regulator_summary.

Fix this by explicitly handling "deviceless" consumers in the debugfs code.

Signed-off-by: Leonard Crestez 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

regulator: stw481x-vmmc: fix ages old enable error

2017-01-13T01:56:53+00:00

[ Upstream commit 295070e9aa015abb9b92cccfbb1e43954e938133 ]

The regulator has never been properly enabled, it has been
dormant all the time. It's strange that MMC was working
at all, but it likely worked by the signals going through
the levelshifter and reaching the card anyways.

Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver")
Signed-off-by: Linus Walleij 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

regulator: s5m8767: fix get_register() error handling

2016-07-11T03:07:12+00:00

[ Upstream commit e07ff9434167981c993a26d2edbbcb8e13801dbb ]

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: Sasha Levin

regulator: Try to resolve regulators supplies on registration

2016-06-01T20:08:57+00:00

[ Upstream commit 5e3ca2b349b1e2c80b060b51bbf2af37448fad85 ]

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 
Cc:  # 4.1+
Signed-off-by: Sasha Levin

regulator: core: Use class device list for regulator_list in late init

2016-06-01T20:08:52+00:00

[ Upstream commit 609ca5f3cb32c2d11fd8cabe293ff3689e7d2613 ]

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 
Signed-off-by: Sasha Levin

regulator: s2mps11: Fix invalid selector mask and voltages for buck9

2016-05-17T17:42:35+00:00

[ Upstream commit 3b672623079bb3e5685b8549e514f2dfaa564406 ]

The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
instead of 0x1f) thus reading entire register as buck9's voltage. This
effectively caused regulator core to interpret values as higher voltages
than they were and then to set real voltage much lower than intended.

The buck9 provides power to other regulators, including LDO13
and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
voltage caused SD card detection errors on Odroid XU3/XU4:
	mmc1: card never left busy state
	mmc1: error -110 whilst initialising SD card

During driver probe the regulator core was checking whether initial
voltage matches the constraints. With incorrect vsel_mask of 0xff and
default value of 0x50, the core interpreted this as 5 V which is outside
of constraints (3-3.775 V). Then the regulator core was adjusting the
voltage to match the constraints. With incorrect vsel_mask this new
voltage mapped to a vere low voltage in the driver.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Mark Brown 
Cc: 
Signed-off-by: Sasha Levin

regulator: pbias: Fix broken pbias disable functionality

2015-09-21T17:05:43+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: Greg Kroah-Hartman

regulator: s2mps11: Fix GPIO suspend enable shift wrapping bug

2015-08-10T19:21:56+00:00

commit 32c848e33ace75fce388cceff76223d12b46eaa3 upstream.

Status of enabling suspend mode for regulator was stored in bitmap-like
long integer.

However since adding support for S2MPU02 the number of regulators
exceeded 32 so on devices with more than 32 regulators (S2MPU02 and
S2MPS13) overflow happens when shifting the bit. This could lead to
enabling suspend mode for completely different regulator than intended
or to switching different regulator to other mode (e.g. from always
enabled to controlled by PWRHOLD pin). Both cases could result in larger
energy usage and issues when suspending to RAM.

Fixes: 00e2573d2c10 ("regulator: s2mps11: Add support S2MPU02 regulator device")
Reported-by: Dan Carpenter 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

regulator: core: fix constraints output buffer

2015-07-21T17:10:04+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: Greg Kroah-Hartman