linux-stable.git/drivers/regulator, branch v5.3.4

regulator: Defer init completion for a while after late_initcall

2019-10-05T13:12:24+00:00

commit 55576cf1853798e86f620766e23b604c9224c19c upstream.

The kernel has no way of knowing when we have finished instantiating
drivers, between deferred probe and systems that build key drivers as
modules we might be doing this long after userspace has booted. This has
always been a bit of an issue with regulator_init_complete since it can
power off hardware that's not had it's driver loaded which can result in
user visible effects, the main case is powering off displays. Practically
speaking it's not been an issue in real systems since most systems that
use the regulator API are embedded and build in key drivers anyway but
with Arm laptops coming on the market it's becoming more of an issue so
let's do something about it.

In the absence of any better idea just defer the powering off for 30s
after late_initcall(), this is obviously a hack but it should mask the
issue for now and it's no more arbitrary than late_initcall() itself.
Ideally we'd have some heuristics to detect if we're on an affected
system and tune or skip the delay appropriately, and there may be some
need for a command line option to be added.

Link: https://lore.kernel.org/r/20190904124250.25844-1-broonie@kernel.org
Signed-off-by: Mark Brown 
Tested-by: Lee Jones 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

regulator: lm363x: Fix n_voltages setting for lm36274

2019-10-05T13:11:25+00:00

[ Upstream commit 962f170d9344e5d9edb3903971c591f42d55e226 ]

According to the datasheet http://www.ti.com/lit/ds/symlink/lm36274.pdf:
Table 23. VPOS Bias Register Field Descriptions VPOS[5:0]:
VPOS voltage (50-mV steps): VPOS = 4 V + (Code × 50 mV), 6.5 V max
000000 = 4 V
000001 = 4.05 V
:
011110 = 5.5 V (Default)
:
110010 = 6.5 V
110011 to 111111 map to 6.5 V

So the LM36274_LDO_VSEL_MAX should be 0b110010 (0x32).
The valid selectors are 0 ... LM36274_LDO_VSEL_MAX, n_voltages should be
LM36274_LDO_VSEL_MAX + 1. Similarly, the n_voltages should be
LM36274_BOOST_VSEL_MAX + 1 for LM36274_BOOST.

Fixes: bff5e8071533 ("regulator: lm363x: Add support for LM36274")
Signed-off-by: Axel Lin 
Link: https://lore.kernel.org/r/20190626132632.32629-2-axel.lin@ingics.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: lm363x: Fix off-by-one n_voltages for lm3632 ldo_vpos/ldo_vneg

2019-10-05T13:11:25+00:00

[ Upstream commit 1e2cc8c5e0745b545d4974788dc606d678b6e564 ]

According to the datasheet https://www.ti.com/lit/ds/symlink/lm3632a.pdf
Table 20. VPOS Bias Register Field Descriptions VPOS[5:0]
Sets the Positive Display Bias (LDO) Voltage (50 mV per step)
000000: 4 V
000001: 4.05 V
000010: 4.1 V
....................
011101: 5.45 V
011110: 5.5 V (Default)
011111: 5.55 V
....................
100111: 5.95 V
101000: 6 V
Note: Codes 101001 to 111111 map to 6 V

The LM3632_LDO_VSEL_MAX should be 0b101000 (0x28), so the maximum voltage
can match the datasheet.

Fixes: 3a8d1a73a037 ("regulator: add LM363X driver")
Signed-off-by: Axel Lin 
Link: https://lore.kernel.org/r/20190626132632.32629-1-axel.lin@ingics.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

regulator: twl: voltage lists for vdd1/2 on twl4030

2019-08-15T14:08:41+00:00

_opp_supported_by_regulators() wrongly ignored errors from
regulator_is_supported_voltage(), so it considered errors as
success. Since
commit 498209445124 ("regulator: core: simplify return value on suported_voltage")
regulator_is_supported_voltage() returns a real boolean, so
errors make _opp_supported_by_regulators() return false.

That reveals a problem with the declaration of the VDD1/2
regulators on twl4030.
The VDD1/VDD2 regulators on twl4030 are neither defined with
voltage lists nor with the continuous flag set, so
regulator_is_supported_voltage() returns false and an error
before above mentioned commit (which was considered success)
The result is that after the above mentioned commit cpufreq
does not work properly e.g. dm3730.

[    2.490997] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV: 1012500, not supported by regulator
[    2.501617] cpu cpu0: _opp_add: OPP not supported by regulators (300000000)
[    2.509246] core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator
[    2.519775] cpu cpu0: _opp_add: OPP not supported by regulators (600000000)
[    2.527313] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV: 1325000, not supported by regulator
[    2.537750] cpu cpu0: _opp_add: OPP not supported by regulators (800000000)

The patch fixes declaration of VDD1/2 regulators by
adding proper voltage lists.

Fixes: 498209445124 ("regulator: core: simplify return value on suported_voltage")
Cc: stable@vger.kernel.org
Signed-off-by: Andreas Kemnade 
Tested-by: Adam Ford  #logicpd-torpedo-37xx-devkit
Link: https://lore.kernel.org/r/20190814214319.24087-1-andreas@kemnade.info
Signed-off-by: Mark Brown

regulator: act8945a-regulator: fix ldo register addresses in set_mode hook

2019-08-13T11:41:46+00:00

According to ACT8945A datasheet[1], operating modes for ldos are
controlled by BIT(5) of their respective _CTRL registers.

[1] https://active-semi.com/wp-content/uploads/ACT8945A_Datasheet.pdf

Fixes: 7482d6ecc68e ("regulator: act8945a-regulator: Implement PM functionalities")
Signed-off-by: Raag Jadav 
Link: https://lore.kernel.org/r/1565635194-5816-1-git-send-email-raagjadav@gmail.com
Signed-off-by: Mark Brown

regulator: slg51000: Fix a couple NULL vs IS_ERR() checks

2019-08-08T19:41:09+00:00

The devm_gpiod_get_from_of_node() function never returns NULL, it
returns error pointers on error.

Fixes: a867bde3dd03 ("regulator: slg51000: add slg51000 regulator driver")
Signed-off-by: Dan Carpenter 
Link: https://lore.kernel.org/r/20190808103335.GD30506@mwanda
Signed-off-by: Mark Brown

regulator: of: Add of_node_put() before return in function

2019-08-01T13:07:46+00:00

The local variable search in regulator_of_get_init_node takes the value
returned by either of_get_child_by_name or of_node_get, both of which
get a node. If this node is not put before returning, it could cause a
memory leak. Hence put search before a mid-loop return statement.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
Link: https://lore.kernel.org/r/20190724083231.10276-1-nishkadg.linux@gmail.com
Signed-off-by: Mark Brown

regulator: lp87565: Fix probe failure for "ti,lp87565"

2019-07-24T16:03:34+00:00

The "ti,lp87565" compatible string is still in of_lp87565_match_table,
but current code will return -EINVAL because lp87565->dev_type is unknown.
This was working in earlier kernel versions, so fix it.

Fixes: 7ee63bd74750 ("regulator: lp87565: Add 4-phase lp87561 regulator support")
Signed-off-by: Axel Lin 
Link: https://lore.kernel.org/r/20190711113517.26077-1-axel.lin@ingics.com
Signed-off-by: Mark Brown

Merge tag 'v5.3-rc1' into regulator-5.3

2019-07-24T16:00:06+00:00

Linus 5.3-rc1

regulator: axp20x: fix DCDC5 and DCDC6 for AXP803

2019-07-16T18:14:14+00:00

Refactoring of axp20x driver introduced a bug in AXP803's DCDC6
regulator definition. AXP803_DCDC6_1120mV_STEPS was obtained by
subtracting 0x47 and 0x33. This should be 0x14 (hex) and not 14
(dec).

Refactoring also carried over a bug in DCDC5 regulator definition.
Number of possible voltages must be for 1 bigger than maximum valid
voltage index, because 0 is also valid and it means lowest voltage.

Fixes: 1dbe0ccb0631 ("regulator: axp20x-regulator: add support for AXP803")
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Signed-off-by: Jernej Skrabec 
Link: https://lore.kernel.org/r/20190713090717.347-3-jernej.skrabec@siol.net
Signed-off-by: Mark Brown