<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/regulator, branch v4.14.217</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.217'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-11-24T12:05:55+00:00</updated>
<entry>
<title>regulator: workaround self-referent regulators</title>
<updated>2020-11-24T12:05:55+00:00</updated>
<author>
<name>Michał Mirosław</name>
<email>mirq-linux@rere.qmqm.pl</email>
</author>
<published>2020-11-13T00:20:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52ad1338d3b6c3adf03f1c1930b0e973f500f92d'/>
<id>urn:sha1:52ad1338d3b6c3adf03f1c1930b0e973f500f92d</id>
<content type='text'>
commit f5c042b23f7429e5c2ac987b01a31c69059a978b upstream.

Workaround regulators whose supply name happens to be the same as its
own name. This fixes boards that used to work before the early supply
resolving was removed. The error message is left in place so that
offending drivers can be detected.

Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Reported-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt;
Signed-off-by: Michał Mirosław &lt;mirq-linux@rere.qmqm.pl&gt;
Tested-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt; # stpmic1
Link: https://lore.kernel.org/r/d703acde2a93100c3c7a81059d716c50ad1b1f52.1605226675.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>regulator: avoid resolve_supply() infinite recursion</title>
<updated>2020-11-24T12:05:55+00:00</updated>
<author>
<name>Michał Mirosław</name>
<email>mirq-linux@rere.qmqm.pl</email>
</author>
<published>2020-11-13T00:20:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=791f93bbc33025d9aeee9860525e5b6c920aaa60'/>
<id>urn:sha1:791f93bbc33025d9aeee9860525e5b6c920aaa60</id>
<content type='text'>
commit 4b639e254d3d4f15ee4ff2b890a447204cfbeea9 upstream.

When a regulator's name equals its supply's name the
regulator_resolve_supply() recurses indefinitely. Add a check
so that debugging the problem is easier. The "fixed" commit
just exposed the problem.

Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Reported-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt;
Signed-off-by: Michał Mirosław &lt;mirq-linux@rere.qmqm.pl&gt;
Tested-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt; # stpmic1
Link: https://lore.kernel.org/r/c6171057cfc0896f950c4d8cb82df0f9f1b89ad9.1605226675.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>regulator: fix memory leak with repeated set_machine_constraints()</title>
<updated>2020-11-24T12:05:54+00:00</updated>
<author>
<name>Michał Mirosław</name>
<email>mirq-linux@rere.qmqm.pl</email>
</author>
<published>2020-11-13T00:20:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=961d46301da28bf3d3f5b5a32f6b2359890e4901'/>
<id>urn:sha1:961d46301da28bf3d3f5b5a32f6b2359890e4901</id>
<content type='text'>
commit 57a6ad482af256b2a13de14194fb8f67c1a65f10 upstream.

Fixed commit introduced a possible second call to
set_machine_constraints() and that allocates memory for
rdev-&gt;constraints. Move the allocation to the caller so
it's easier to manage and done once.

Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Signed-off-by: Michał Mirosław &lt;mirq-linux@rere.qmqm.pl&gt;
Tested-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt; # stpmic1
Link: https://lore.kernel.org/r/78c3d4016cebc08d441aad18cb924b4e4d9cf9df.1605226675.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>regulator: ti-abb: Fix array out of bound read access on the first transition</title>
<updated>2020-11-24T12:05:49+00:00</updated>
<author>
<name>Nishanth Menon</name>
<email>nm@ti.com</email>
</author>
<published>2020-11-18T14:50:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=274663e922110cff99046ddce533899118f9215f'/>
<id>urn:sha1:274663e922110cff99046ddce533899118f9215f</id>
<content type='text'>
[ Upstream commit 2ba546ebe0ce2af47833d8912ced9b4a579f13cb ]

At the start of driver initialization, we do not know what bias
setting the bootloader has configured the system for and we only know
for certain the very first time we do a transition.

However, since the initial value of the comparison index is -EINVAL,
this negative value results in an array out of bound access on the
very first transition.

Since we don't know what the setting is, we just set the bias
configuration as there is nothing to compare against. This prevents
the array out of bound access.

NOTE: Even though we could use a more relaxed check of "&lt; 0" the only
valid values(ignoring cosmic ray induced bitflips) are -EINVAL, 0+.

Fixes: 40b1936efebd ("regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver")
Link: https://lore.kernel.org/linux-mm/CA+G9fYuk4imvhyCN7D7T6PMDH6oNp6HDCRiTUKMQ6QXXjBa4ag@mail.gmail.com/
Reported-by: Naresh Kamboju &lt;naresh.kamboju@linaro.org&gt;
Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Nishanth Menon &lt;nm@ti.com&gt;
Link: https://lore.kernel.org/r/20201118145009.10492-1-nm@ti.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: defer probe when trying to get voltage from unresolved supply</title>
<updated>2020-11-18T17:27:52+00:00</updated>
<author>
<name>Michał Mirosław</name>
<email>mirq-linux@rere.qmqm.pl</email>
</author>
<published>2020-11-02T21:27:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f31e8dea41926ca67f7c9ebb180bf6082d9707c5'/>
<id>urn:sha1:f31e8dea41926ca67f7c9ebb180bf6082d9707c5</id>
<content type='text'>
[ Upstream commit cf1ad559a20d1930aa7b47a52f54e1f8718de301 ]

regulator_get_voltage_rdev() is called in regulator probe() when
applying machine constraints.  The "fixed" commit exposed the problem
that non-bypassed regulators can forward the request to its parent
(like bypassed ones) supply. Return -EPROBE_DEFER when the supply
is expected but not resolved yet.

Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
Cc: stable@vger.kernel.org
Signed-off-by: Michał Mirosław &lt;mirq-linux@rere.qmqm.pl&gt;
Reported-by: Ondřej Jirman &lt;megous@megous.com&gt;
Reported-by: Corentin Labbe &lt;clabbe.montjoie@gmail.com&gt;
Tested-by: Ondřej Jirman &lt;megous@megous.com&gt;
Link: https://lore.kernel.org/r/a9041d68b4d35e4a2dd71629c8a6422662acb5ee.1604351936.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: resolve supply after creating regulator</title>
<updated>2020-10-29T08:07:02+00:00</updated>
<author>
<name>Michał Mirosław</name>
<email>mirq-linux@rere.qmqm.pl</email>
</author>
<published>2020-09-26T21:32:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=167c3b1f9793a1fb23e75e693f078420850306d4'/>
<id>urn:sha1:167c3b1f9793a1fb23e75e693f078420850306d4</id>
<content type='text'>
[ Upstream commit aea6cb99703e17019e025aa71643b4d3e0a24413 ]

When creating a new regulator its supply cannot create the sysfs link
because the device is not yet published. Remove early supply resolving
since it will be done later anyway. This makes the following error
disappear and the symlinks get created instead.

  DCDC_REG1: supplied by VSYS
  VSYS: could not add device link regulator.3 err -2

Note: It doesn't fix the problem for bypassed regulators, though.

Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: Michał Mirosław &lt;mirq-linux@rere.qmqm.pl&gt;
Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: push allocation in set_consumer_device_supply() out of lock</title>
<updated>2020-09-23T08:46:30+00:00</updated>
<author>
<name>Michał Mirosław</name>
<email>mirq-linux@rere.qmqm.pl</email>
</author>
<published>2020-08-12T01:31:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d85ba0676a856259fe36abe8d21364842cc729e'/>
<id>urn:sha1:0d85ba0676a856259fe36abe8d21364842cc729e</id>
<content type='text'>
commit 5c06540165d443c6455123eb48e7f1a9b618ab34 upstream.

Pull regulator_list_mutex into set_consumer_device_supply() and keep
allocations outside of it. Fourth of the fs_reclaim deadlock case.

Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators")
Signed-off-by: Michał Mirosław &lt;mirq-linux@rere.qmqm.pl&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>regulator: rk808: Lower log level on optional GPIOs being not available</title>
<updated>2020-02-28T15:35:59+00:00</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2019-12-03T16:47:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b99bcff0147d069adbc68349a2a8bbe40855c2f2'/>
<id>urn:sha1:b99bcff0147d069adbc68349a2a8bbe40855c2f2</id>
<content type='text'>
[ Upstream commit b8a039d37792067c1a380dc710361905724b9b2f ]

RK808 can leverage a couple of GPIOs to tweak the ramp rate during DVS
(Dynamic Voltage Scaling). These GPIOs are entirely optional but a
dev_warn() appeared when cleaning this driver to use a more up-to-date
gpiod API. At least reduce the log level to 'info' as it is totally
fine to not populate these GPIO on a hardware design.

This change is trivial but it is worth not polluting the logs during
bringup phase by having real warnings and errors sorted out
correctly.

Fixes: a13eaf02e2d6 ("regulator: rk808: make better use of the gpiod API")
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://lore.kernel.org/r/20191203164709.11127-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: tps65086: Fix tps65086_ldoa1_ranges for selector 0xB</title>
<updated>2020-01-27T13:46:26+00:00</updated>
<author>
<name>Axel Lin</name>
<email>axel.lin@ingics.com</email>
</author>
<published>2019-03-04T08:57:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=96ef352408a62a567c38b02b39bb87a5efb4c375'/>
<id>urn:sha1:96ef352408a62a567c38b02b39bb87a5efb4c375</id>
<content type='text'>
[ Upstream commit e69b394703e032e56a140172440ec4f9890b536d ]

selector 0xB (1011) should be 2.6V rather than 2.7V, fit ix.

Table 5-4. LDOA1 Output Voltage Options
VID Bits VOUT VID Bits VOUT VID Bits VOUT VID Bits VOUT
0000     1.35 0100     1.8  1000     2.3  1100     2.85
0001     1.5  0101     1.9  1001     2.4  1101     3.0
0010     1.6  0110     2.0  1010     2.5  1110     3.3
0011     1.7  0111     2.1  1011     2.6  1111     Not Used

Fixes: d2a2e729a666 ("regulator: tps65086: Add regulator driver for the TPS65086 PMIC")
Signed-off-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Acked-by: Andrew F. Davis &lt;afd@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: lp87565: Fix missing register for LP87565_BUCK_0</title>
<updated>2020-01-27T13:46:26+00:00</updated>
<author>
<name>Axel Lin</name>
<email>axel.lin@ingics.com</email>
</author>
<published>2019-03-01T06:16:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d0d7c1cbd50bc1d32e37ea9b92c30b66075979b5'/>
<id>urn:sha1:d0d7c1cbd50bc1d32e37ea9b92c30b66075979b5</id>
<content type='text'>
[ Upstream commit d1a6cbdf1e597917cb642c655512d91b71a35d22 ]

LP87565_BUCK_0 is missed, fix it.

Fixes: f0168a9bf ("regulator: lp87565: Add support for lp87565 PMIC regulators")
Signed-off-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Reviewed-by: Keerthy &lt;j-keerthy@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
