<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/regulator/devres.c, branch v6.12.80</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.80'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-08-29T13:20:30+00:00</updated>
<entry>
<title>regulator: Unify "negative error number" terminology in comments</title>
<updated>2024-08-29T13:20:30+00:00</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wenst@chromium.org</email>
</author>
<published>2024-08-29T08:51:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98ce82a52886edd5197e903cb2b56f21bf3b0781'/>
<id>urn:sha1:98ce82a52886edd5197e903cb2b56f21bf3b0781</id>
<content type='text'>
Previous commits cleaning up kerneldoc used the term "negative error
number" to refer to error condition return values. Update remaining
instances of other terminology such as "error code" or "errno" as
well so the whole regulator subsystem is unified.

Signed-off-by: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Reported-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://patch.msgid.link/20240829085131.1361701-11-wenst@chromium.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: devres: fix devm_regulator_get_enable_read_voltage() return</title>
<updated>2024-05-07T01:31:47+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2024-05-06T15:59:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=257b2335eebf51e318db1f3b2d023512da46fa66'/>
<id>urn:sha1:257b2335eebf51e318db1f3b2d023512da46fa66</id>
<content type='text'>
The devm_regulator_get_enable_read_voltage() function is supposed to
return the voltage that the regulator is currently set to. However, it
currently returns 0.

Fixes: b250c20b6429 ("regulator: devres: add API for reference voltage supplies")
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20240506-regulator-devm_regulator_get_enable_read_voltage-fixes-v1-1-356cdd152067@baylibre.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: devres: add API for reference voltage supplies</title>
<updated>2024-05-03T02:08:12+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2024-04-29T23:40:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b250c20b64290808aa4b5cc6d68819a7ee28237f'/>
<id>urn:sha1:b250c20b64290808aa4b5cc6d68819a7ee28237f</id>
<content type='text'>
A common use case for regulators is to supply a reference voltage to an
analog input or output device. This adds a new devres API to get,
enable, and get the voltage in a single call. This allows eliminating
boilerplate code in drivers that use reference supplies in this way.

Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20240429-regulator-get-enable-get-votlage-v2-1-b1f11ab766c1@baylibre.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: Use different devices for resource allocation and DT lookup</title>
<updated>2022-12-08T13:02:37+00:00</updated>
<author>
<name>ChiYuan Huang</name>
<email>cy_huang@richtek.com</email>
</author>
<published>2022-12-06T07:22:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8f3cbcd6b440032ebc7f7d48a1689dcc70a4eb98'/>
<id>urn:sha1:8f3cbcd6b440032ebc7f7d48a1689dcc70a4eb98</id>
<content type='text'>
Following by the below discussion, there's the potential UAF issue
between regulator and mfd.
https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/

From the analysis of Yingliang

CPU A				|CPU B
mt6370_probe()			|
  devm_mfd_add_devices()	|
				|mt6370_regulator_probe()
				|  regulator_register()
				|    //allocate init_data and add it to devres
				|    regulator_of_get_init_data()
i2c_unregister_device()		|
  device_del()			|
    devres_release_all()	|
      // init_data is freed	|
      release_nodes()		|
				|  // using init_data causes UAF
				|  regulator_register()

It's common to use mfd core to create child device for the regulator.
In order to do the DT lookup for init data, the child that registered
the regulator would pass its parent as the parameter. And this causes
init data resource allocated to its parent, not itself. The issue happen
when parent device is going to release and regulator core is still doing
some operation of init data constraint for the regulator of child device.

To fix it, this patch expand 'regulator_register' API to use the
different devices for init data allocation and DT lookup.

Reported-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Signed-off-by: ChiYuan Huang &lt;cy_huang@richtek.com&gt;
Link: https://lore.kernel.org/r/1670311341-32664-1-git-send-email-u0084500@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: devres: Add devm_regulator_bulk_get_exclusive()</title>
<updated>2022-11-03T13:34:53+00:00</updated>
<author>
<name>Zev Weiss</name>
<email>zev@bewilderbeest.net</email>
</author>
<published>2022-10-31T23:37:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd1845069711cdf1b1aaaa0f22311b7736396331'/>
<id>urn:sha1:fd1845069711cdf1b1aaaa0f22311b7736396331</id>
<content type='text'>
We had an exclusive variant of the devm_regulator_get() API, but no
corresponding variant for the bulk API; let's add one now.  We add a
generalized version of the existing regulator_bulk_get() function that
additionally takes a get_type parameter and redefine
regulator_bulk_get() in terms of it, then do similarly with
devm_regulator_bulk_get(), and finally add the new
devm_regulator_bulk_get_exclusive().

Signed-off-by: Zev Weiss &lt;zev@bewilderbeest.net&gt;
Link: https://lore.kernel.org/r/20221031233704.22575-2-zev@bewilderbeest.net
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: Add devm helpers for get and enable</title>
<updated>2022-08-18T11:51:48+00:00</updated>
<author>
<name>Matti Vaittinen</name>
<email>mazziesaccount@gmail.com</email>
</author>
<published>2022-08-12T10:10:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=da279e6965b3838e99e5c0ab8f76b87bf86b31a5'/>
<id>urn:sha1:da279e6965b3838e99e5c0ab8f76b87bf86b31a5</id>
<content type='text'>
A few regulator consumer drivers seem to be just getting a regulator,
enabling it and registering a devm-action to disable the regulator at
the driver detach and then forget about it.

We can simplify this a bit by adding a devm-helper for this pattern.
Add devm_regulator_get_enable() and devm_regulator_get_enable_optional()

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Link: https://lore.kernel.org/r/ed7b8841193bb9749d426f3cb3b199c9460794cd.1660292316.git.mazziesaccount@gmail.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: core: Allow drivers to define their init data as const</title>
<updated>2022-07-27T12:47:30+00:00</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2022-07-26T17:38:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1de452a0edda26f1483d1d934f692eab13ba669a'/>
<id>urn:sha1:1de452a0edda26f1483d1d934f692eab13ba669a</id>
<content type='text'>
Drivers tend to want to define the names of their regulators somewhere
in their source file as "static const". This means, inevitable, that
every driver out there open codes something like this:

static const char * const supply_names[] = {
 "vcc", "vccl",
};

static int get_regulators(struct my_data *data)
{
  int i;

  data-&gt;supplies = devm_kzalloc(...)
  if (!data-&gt;supplies)
    return -ENOMEM;

  for (i = 0; i &lt; ARRAY_SIZE(supply_names); i++)
    data-&gt;supplies[i].supply = supply_names[i];

  return devm_regulator_bulk_get(data-&gt;dev,
                                 ARRAY_SIZE(supply_names),
				 data-&gt;supplies);
}

Let's make this more convenient by doing providing a helper that does
the copy.

I have chosen to have the "const" input structure here be the exact
same structure as the normal one passed to
devm_regulator_bulk_get(). This is slightly inefficent since the input
data can't possibly have anything useful for "ret" or consumer and
thus we waste 8 bytes per structure. This seems an OK tradeoff for not
introducing an extra structure.

Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Link: https://lore.kernel.org/r/20220726103631.v2.6.I38fc508a73135a5c1b873851f3553ff2a3a625f5@changeid
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: devres: unexport devm_regulator_unregister_supply_alias()</title>
<updated>2021-07-11T22:50:34+00:00</updated>
<author>
<name>Alexandru Ardelean</name>
<email>aardelean@deviqon.com</email>
</author>
<published>2021-06-25T12:23:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d9f4d1de3ceb84fa6ce68177a26b8fac6a71290'/>
<id>urn:sha1:4d9f4d1de3ceb84fa6ce68177a26b8fac6a71290</id>
<content type='text'>
This API hook isn't used anywhere outside of the regulator devres code.
This function is needed for the devm_regulator_bulk_register_supply_alias()
function on the error path, to cleanup any previously registered supply
aliases.

This change makes the devm_regulator_unregister_supply_alias() local to the
regulator core framework, to avoid it being used in any weird logic.
It's also removing the doc-string for
devm_regulator_unregister_supply_alias(), since it doesn't need to be
documented anymore, as no other external consumer should use it.

Signed-off-by: Alexandru Ardelean &lt;aardelean@deviqon.com&gt;
Link: https://lore.kernel.org/r/20210625122324.327585-5-aardelean@deviqon.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: devres: remove devm_regulator_bulk_unregister_supply_alias()</title>
<updated>2021-07-11T22:50:33+00:00</updated>
<author>
<name>Alexandru Ardelean</name>
<email>aardelean@deviqon.com</email>
</author>
<published>2021-06-25T12:23:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eed43b96ede9c3f018ad24149de83f24b86ad729'/>
<id>urn:sha1:eed43b96ede9c3f018ad24149de83f24b86ad729</id>
<content type='text'>
This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.

For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.

Removing this also discourages any weird logic that could be created with
such an API function.

Signed-off-by: Alexandru Ardelean &lt;aardelean@deviqon.com&gt;
Link: https://lore.kernel.org/r/20210625122324.327585-4-aardelean@deviqon.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
<entry>
<title>regulator: devres: remove devm_regulator_unregister() function</title>
<updated>2021-07-11T22:50:32+00:00</updated>
<author>
<name>Alexandru Ardelean</name>
<email>aardelean@deviqon.com</email>
</author>
<published>2021-06-25T12:23:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4ff75a29976590bc7afe3ed75d547c1f2a924c75'/>
<id>urn:sha1:4ff75a29976590bc7afe3ed75d547c1f2a924c75</id>
<content type='text'>
This API hook isn't used anywhere and most-likely exists because of the
general principle of C APIs, where if an API function does an
allocation/registration, it must also have an equivalent
deallocation/deregistration counterpart.

For devm_ functions this isn't all that true (for all cases), as the idea
of these function is to provide an auto-cleanup logic on drivers/system
de-init.

Removing this also discourages any weird logic that could be created with
such an API function.

Signed-off-by: Alexandru Ardelean &lt;aardelean@deviqon.com&gt;
Link: https://lore.kernel.org/r/20210625122324.327585-3-aardelean@deviqon.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
</content>
</entry>
</feed>
