<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/regulator, branch dev-5.15-intel</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.15-intel</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.15-intel'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2022-04-20T07:34:16+00:00</updated>
<entry>
<title>regulator: wm8994: Add an off-on delay for WM8994 variant</title>
<updated>2022-04-20T07:34:16+00:00</updated>
<author>
<name>Jonathan Bakker</name>
<email>xc-racer2@live.ca</email>
</author>
<published>2022-03-28T01:01:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=cfd24b14eb2d435d4555e9bc15d68d50bd21c105'/>
<id>urn:sha1:cfd24b14eb2d435d4555e9bc15d68d50bd21c105</id>
<content type='text'>
[ Upstream commit 92d96b603738ec4f35cde7198c303ae264dd47cb ]

As per Table 130 of the wm8994 datasheet at [1], there is an off-on
delay for LDO1 and LDO2.  In the wm8958 datasheet [2], I could not
find any reference to it.  I could not find a wm1811 datasheet to
double-check there, but as no one has complained presumably it works
without it.

This solves the issue on Samsung Aries boards with a wm8994 where
register writes fail when the device is powered off and back-on
quickly.

[1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf
[2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf

Signed-off-by: Jonathan Bakker &lt;xc-racer2@live.ca&gt;
Acked-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Link: https://lore.kernel.org/r/CY4PR04MB056771CFB80DC447C30D5A31CB1D9@CY4PR04MB0567.namprd04.prod.outlook.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: atc260x: Fix missing active_discharge_on setting</title>
<updated>2022-04-13T18:59:17+00:00</updated>
<author>
<name>Axel Lin</name>
<email>axel.lin@ingics.com</email>
</author>
<published>2022-04-03T13:22:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=cb713eb793e6f308d91ffa2f483d2c59e6c2e3ad'/>
<id>urn:sha1:cb713eb793e6f308d91ffa2f483d2c59e6c2e3ad</id>
<content type='text'>
[ Upstream commit 2316f0fc0ad2aa87a568ceaf3d76be983ee555c3 ]

Without active_discharge_on setting, the SWITCH1 discharge enable control
is always disabled. Fix it.

Fixes: 3b15ccac161a ("regulator: Add regulator driver for ATC260x PMICs")
Signed-off-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Link: https://lore.kernel.org/r/20220403132235.123727-1-axel.lin@ingics.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: rtq2134: Fix missing active_discharge_on setting</title>
<updated>2022-04-13T18:59:16+00:00</updated>
<author>
<name>Axel Lin</name>
<email>axel.lin@ingics.com</email>
</author>
<published>2022-04-04T02:25:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=336942b1682ff3bed87ea0cc8c44c77b39b28c5f'/>
<id>urn:sha1:336942b1682ff3bed87ea0cc8c44c77b39b28c5f</id>
<content type='text'>
[ Upstream commit 17049bf9de55a42ee96fd34520aff8a484677675 ]

The active_discharge_on setting was missed, so output discharge resistor
is always disabled. Fix it.

Fixes: 0555d41497de ("regulator: rtq2134: Add support for Richtek RTQ2134 SubPMIC")
Signed-off-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Link: https://lore.kernel.org/r/20220404022514.449231-1-axel.lin@ingics.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: rpi-panel: Handle I2C errors/timing to the Atmel</title>
<updated>2022-04-08T12:23:54+00:00</updated>
<author>
<name>Dave Stevenson</name>
<email>dave.stevenson@raspberrypi.com</email>
</author>
<published>2022-01-24T22:01:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=4941c21090c3f7398735d198deb0e37dcb29dd5d'/>
<id>urn:sha1:4941c21090c3f7398735d198deb0e37dcb29dd5d</id>
<content type='text'>
[ Upstream commit 5665eee7a3800430e7dc3ef6f25722476b603186 ]

The Atmel is doing some things in the I2C ISR, during which
period it will not respond to further commands. This is
particularly true of the POWERON command.

Increase delays appropriately, and retry should I2C errors be
reported.

Signed-off-by: Dave Stevenson &lt;dave.stevenson@raspberrypi.com&gt;
Signed-off-by: Detlev Casanova &lt;detlev.casanova@collabora.com&gt;
Link: https://lore.kernel.org/r/20220124220129.158891-3-detlev.casanova@collabora.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: qcom_smd: fix for_each_child.cocci warnings</title>
<updated>2022-04-08T12:23:04+00:00</updated>
<author>
<name>kernel test robot</name>
<email>lkp@intel.com</email>
</author>
<published>2022-01-15T11:11:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ae2ff8d991b6479d1aa6496db40948b6806c7f0f'/>
<id>urn:sha1:ae2ff8d991b6479d1aa6496db40948b6806c7f0f</id>
<content type='text'>
[ Upstream commit 6390d42c21efff0b4c10956a38e341f4e84ecd3d ]

drivers/regulator/qcom_smd-regulator.c:1318:1-33: WARNING: Function "for_each_available_child_of_node" should have of_node_put() before return around line 1321.

Semantic patch information:
 False positives can be due to function calls within the for_each
 loop that may encapsulate an of_node_put.

Generated by: scripts/coccinelle/iterators/for_each_child.cocci

Fixes: 14e2976fbabd ("regulator: qcom_smd: Align probe function with rpmh-regulator")
CC: Konrad Dybcio &lt;konrad.dybcio@somainline.org&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Julia Lawall &lt;julia.lawall@inria.fr&gt;
Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2201151210170.3051@hadrien
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: core: fix false positive in regulator_late_cleanup()</title>
<updated>2022-03-08T18:12:29+00:00</updated>
<author>
<name>Oliver Barta</name>
<email>oliver.barta@aptiv.com</email>
</author>
<published>2022-02-08T08:46:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=700485846e128e7c361387ca12f05b48002b0321'/>
<id>urn:sha1:700485846e128e7c361387ca12f05b48002b0321</id>
<content type='text'>
[ Upstream commit 4e2a354e3775870ca823f1fb29bbbffbe11059a6 ]

The check done by regulator_late_cleanup() to detect whether a regulator
is on was inconsistent with the check done by _regulator_is_enabled().
While _regulator_is_enabled() takes the enable GPIO into account,
regulator_late_cleanup() was not doing that.

This resulted in a false positive, e.g. when a GPIO-controlled fixed
regulator was used, which was not enabled at boot time, e.g.

reg_disp_1v2: reg_disp_1v2 {
	compatible = "regulator-fixed";
	regulator-name = "display_1v2";
	regulator-min-microvolt = &lt;1200000&gt;;
	regulator-max-microvolt = &lt;1200000&gt;;
	gpio = &lt;&amp;tlmm 148 0&gt;;
	enable-active-high;
};

Such regulator doesn't have an is_enabled() operation. Nevertheless
it's state can be determined based on the enable GPIO. The check in
regulator_late_cleanup() wrongly assumed that the regulator is on and
tried to disable it.

Signed-off-by: Oliver Barta &lt;oliver.barta@aptiv.com&gt;
Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.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: qcom_smd: Align probe function with rpmh-regulator</title>
<updated>2022-01-27T10:04:54+00:00</updated>
<author>
<name>Konrad Dybcio</name>
<email>konrad.dybcio@somainline.org</email>
</author>
<published>2021-12-30T02:34:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=7828830235cbd6e57ba21ca74a4d1d9bfe41508c'/>
<id>urn:sha1:7828830235cbd6e57ba21ca74a4d1d9bfe41508c</id>
<content type='text'>
[ Upstream commit 14e2976fbabdacb01335d7f91eeebbc89c67ddb1 ]

The RPMh regulator driver is much newer and gets more attention, which in
consequence makes it do a few things better. Update qcom_smd-regulator's
probe function to mimic what rpmh-regulator does to address a couple of
issues:

- Probe defer now works correctly, before it used to, well,
  kinda just die.. This fixes reliable probing on (at least) PM8994,
  because Linux apparently cannot deal with supply map dependencies yet..

- Regulator data is now matched more sanely: regulator data is matched
  against each individual regulator node name and throwing an -EINVAL if
  data is missing, instead of just assuming everything is fine and
  iterating over all subsequent array members.

- status = "disabled" will now work for disabling individual regulators in
  DT. Previously it didn't seem to do much if anything at all.

Signed-off-by: Konrad Dybcio &lt;konrad.dybcio@somainline.org&gt;
Link: https://lore.kernel.org/r/20211230023442.1123424-1-konrad.dybcio@somainline.org
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: da9121: Prevent current limit change when enabled</title>
<updated>2022-01-27T10:04:32+00:00</updated>
<author>
<name>Adam Ward</name>
<email>Adam.Ward.opensource@diasemi.com</email>
</author>
<published>2021-11-29T22:10:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f168858f60962161a32e94acddc5a241327f70aa'/>
<id>urn:sha1:f168858f60962161a32e94acddc5a241327f70aa</id>
<content type='text'>
[ Upstream commit 24f0853228f3b98f1ef08d5824376c69bb8124d2 ]

Prevent changing current limit when enabled as a precaution against
possibile instability due to tight integration with switching cycle

Signed-off-by: Adam Ward &lt;Adam.Ward.opensource@diasemi.com&gt;
Link: https://lore.kernel.org/r/52ee682476004a1736c1e0293358987319c1c415.1638223185.git.Adam.Ward.opensource@diasemi.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: qcom-labibb: OCP interrupts are not a failure while disabled</title>
<updated>2022-01-27T10:03:47+00:00</updated>
<author>
<name>Marijn Suijten</name>
<email>marijn.suijten@somainline.org</email>
</author>
<published>2021-12-24T11:34:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a96546df99ea0851b6839c35ac129c535f0b2d97'/>
<id>urn:sha1:a96546df99ea0851b6839c35ac129c535f0b2d97</id>
<content type='text'>
[ Upstream commit d27bb69dc83f00f86a830298c967052cded6e784 ]

Receiving the Over-Current Protection interrupt while the regulator is
disabled does not count as unhandled/failure (IRQ_NONE, or 0 as it were)
but a "fake event", usually due to inrush as the is regulator about to
be enabled.

Fixes: 390af53e0411 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs")
Signed-off-by: Marijn Suijten &lt;marijn.suijten@somainline.org&gt;
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@somainline.org&gt;
Link: https://lore.kernel.org/r/20211224113450.107958-1-marijn.suijten@somainline.org
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: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled</title>
<updated>2021-11-18T18:15:57+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzysztof.kozlowski@canonical.com</email>
</author>
<published>2021-10-08T11:37:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=e61d145a08254846a8a0ee0d58767b1376a1f7c6'/>
<id>urn:sha1:e61d145a08254846a8a0ee0d58767b1376a1f7c6</id>
<content type='text'>
commit b16bef60a9112b1e6daf3afd16484eb06e7ce792 upstream.

The driver and its bindings, before commit 04f9f068a619 ("regulator:
s5m8767: Modify parsing method of the voltage table of buck2/3/4") were
requiring to provide at least one safe/default voltage for DVS registers
if DVS GPIO is not being enabled.

IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the
s5m8767,pmic-buck2-dvs-voltage should still be present and contain one
voltage.

This requirement was coming from driver behavior matching this condition
(none of DVS GPIO is enabled): it was always initializing the DVS
selector pins to 0 and keeping the DVS enable setting at reset value
(enabled).  Therefore if none of DVS GPIO is enabled in devicetree,
driver was configuring the first DVS voltage for buck[234].

Mentioned commit 04f9f068a619 ("regulator: s5m8767: Modify parsing
method of the voltage table of buck2/3/4") broke it because DVS voltage
won't be parsed from devicetree if DVS GPIO is not enabled.  After the
change, driver will configure bucks to use the register reset value as
voltage which might have unpleasant effects.

Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled
in devicetree (therefore DVS voltage is also not parsed), explicitly
disable it.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4")
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Message-Id: &lt;20211008113723.134648-2-krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
