<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pinctrl/core.c, branch v6.6.132</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.132'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-12-14T19:00:11+00:00</updated>
<entry>
<title>pinmux: Use sequential access to access desc-&gt;pinmux data</title>
<updated>2024-12-14T19:00:11+00:00</updated>
<author>
<name>Mukesh Ojha</name>
<email>quic_mojha@quicinc.com</email>
</author>
<published>2024-10-14T19:29:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b'/>
<id>urn:sha1:2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b</id>
<content type='text'>
[ Upstream commit 5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e ]

When two client of the same gpio call pinctrl_select_state() for the
same functionality, we are seeing NULL pointer issue while accessing
desc-&gt;mux_owner.

Let's say two processes A, B executing in pin_request() for the same pin
and process A updates the desc-&gt;mux_usecount but not yet updated the
desc-&gt;mux_owner while process B see the desc-&gt;mux_usecount which got
updated by A path and further executes strcmp and while accessing
desc-&gt;mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

	cpu0 (process A)			cpu1(process B)

pinctrl_select_state() {		  pinctrl_select_state() {
  pin_request() {				pin_request() {
  ...
						 ....
    } else {
         desc-&gt;mux_usecount++;
    						desc-&gt;mux_usecount &amp;&amp; strcmp(desc-&gt;mux_owner, owner)) {

         if (desc-&gt;mux_usecount &gt; 1)
               return 0;
         desc-&gt;mux_owner = owner;

  }						}

Signed-off-by: Mukesh Ojha &lt;quic_mojha@quicinc.com&gt;
Link: https://lore.kernel.org/20241014192930.1539673-1-quic_mojha@quicinc.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: core: fix possible memory leak when pinctrl_enable() fails</title>
<updated>2024-08-03T06:54:07+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2024-06-06T02:37:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=99ae0689ab5676e6469bc93378c79b01548c595b'/>
<id>urn:sha1:99ae0689ab5676e6469bc93378c79b01548c595b</id>
<content type='text'>
[ Upstream commit ae1cf4759972c5fe665ee4c5e0c29de66fe3cf4a ]

In devm_pinctrl_register(), if pinctrl_enable() fails in pinctrl_register(),
the "pctldev" has not been added to dev resources, so devm_pinctrl_dev_release()
can not be called, it leads memory leak.

Introduce pinctrl_uninit_controller(), call it in the error path to free memory.

Fixes: 5038a66dad01 ("pinctrl: core: delete incorrect free in pinctrl_enable()")
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Link: https://lore.kernel.org/r/20240606023704.3931561-2-yangyingliang@huawei.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Hagar Hemdan</name>
<email>hagarhem@amazon.com</email>
</author>
<published>2024-06-04T08:58:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4038c57bf61631219b31f1bd6e92106ec7f084dc'/>
<id>urn:sha1:4038c57bf61631219b31f1bd6e92106ec7f084dc</id>
<content type='text'>
[ Upstream commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 ]

In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.

This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.

Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Suggested-by: Maximilian Heyne &lt;mheyne@amazon.de&gt;
Signed-off-by: Hagar Hemdan &lt;hagarhem@amazon.com&gt;
Link: https://lore.kernel.org/r/20240604085838.3344-1-hagarhem@amazon.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: core: delete incorrect free in pinctrl_enable()</title>
<updated>2024-05-17T10:01:57+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2024-03-21T06:38:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=558c8039fdf596a584a92c171cbf3298919c448c'/>
<id>urn:sha1:558c8039fdf596a584a92c171cbf3298919c448c</id>
<content type='text'>
[ Upstream commit 5038a66dad0199de60e5671603ea6623eb9e5c79 ]

The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.

The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well.

Fixes: 6118714275f0 ("pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Message-ID: &lt;578fbe56-44e9-487c-ae95-29b695650f7c@moroto.mountain&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: avoid reload of p state in list iteration</title>
<updated>2023-12-08T07:52:15+00:00</updated>
<author>
<name>Maria Yu</name>
<email>quic_aiquny@quicinc.com</email>
</author>
<published>2023-11-15T10:28:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=106d555614ce17677240c9c0ecb481da6d389f3e'/>
<id>urn:sha1:106d555614ce17677240c9c0ecb481da6d389f3e</id>
<content type='text'>
commit 4198a9b571065978632276264e01d71d68000ac5 upstream.

When in the list_for_each_entry iteration, reload of p-&gt;state-&gt;settings
with a local setting from old_state will turn the list iteration into an
infinite loop.

The typical symptom when the issue happens, will be a printk message like:

  "not freeing pin xx (xxx) as part of deactivating group xxx - it is
already used for some other setting".

This is a compiler-dependent problem, one instance occurred using Clang
version 10.0 on the arm64 architecture with linux version 4.19.

Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Maria Yu &lt;quic_aiquny@quicinc.com&gt;
Cc:  &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20231115102824.23727-1-quic_aiquny@quicinc.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "pinctrl: avoid unsafe code pattern in find_pinctrl()"</title>
<updated>2023-10-19T08:12:48+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2023-10-17T14:18:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=62140a1e4dec4594d5d1e1d353747bf2ef434e8b'/>
<id>urn:sha1:62140a1e4dec4594d5d1e1d353747bf2ef434e8b</id>
<content type='text'>
The commit breaks MMC enumeration on the Intel Merrifield
plaform.

Before:
[   36.439057] mmc0: SDHCI controller on PCI [0000:00:01.0] using ADMA
[   36.450924] mmc2: SDHCI controller on PCI [0000:00:01.3] using ADMA
[   36.459355] mmc1: SDHCI controller on PCI [0000:00:01.2] using ADMA
[   36.706399] mmc0: new DDR MMC card at address 0001
[   37.058972] mmc2: new ultra high speed DDR50 SDIO card at address 0001
[   37.278977] mmcblk0: mmc0:0001 H4G1d 3.64 GiB
[   37.297300]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10

After:
[   36.436704] mmc2: SDHCI controller on PCI [0000:00:01.3] using ADMA
[   36.436720] mmc1: SDHCI controller on PCI [0000:00:01.0] using ADMA
[   36.463685] mmc0: SDHCI controller on PCI [0000:00:01.2] using ADMA
[   36.720627] mmc1: new DDR MMC card at address 0001
[   37.068181] mmc2: new ultra high speed DDR50 SDIO card at address 0001
[   37.279998] mmcblk1: mmc1:0001 H4G1d 3.64 GiB
[   37.302670]  mmcblk1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10

This reverts commit c153a4edff6ab01370fcac8e46f9c89cca1060c2.

Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20231017141806.535191-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: avoid unsafe code pattern in find_pinctrl()</title>
<updated>2023-09-25T13:29:26+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2023-09-20T18:09:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c153a4edff6ab01370fcac8e46f9c89cca1060c2'/>
<id>urn:sha1:c153a4edff6ab01370fcac8e46f9c89cca1060c2</id>
<content type='text'>
The code in find_pinctrl() takes a mutex and traverses a list of pinctrl
structures. Later the caller bumps up reference count on the found
structure. Such pattern is not safe as pinctrl that was found may get
deleted before the caller gets around to increasing the reference count.

Fix this by taking the reference count in find_pinctrl(), while it still
holds the mutex.

Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Link: https://lore.kernel.org/r/ZQs1RgTKg6VJqmPs@google.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()</title>
<updated>2023-07-28T20:08:58+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omp.ru</email>
</author>
<published>2023-07-19T20:22:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ecfe9a015d3e1e46504d5b3de7eef1f2d186194a'/>
<id>urn:sha1:ecfe9a015d3e1e46504d5b3de7eef1f2d186194a</id>
<content type='text'>
pinctrl_register_one_pin() doesn't check the result of radix_tree_insert()
despite they both may return a negative error code.  Linus Walleij said he
has copied the radix tree code from kernel/irq/ where the functions calling
radix_tree_insert() are *void* themselves; I think it makes more sense to
propagate the errors from radix_tree_insert() upstream if we can do that...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.

Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omp.ru&gt;
Link: https://lore.kernel.org/r/20230719202253.13469-3-s.shtylyov@omp.ru
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: core: handle radix_tree_insert() errors in pinctrl_generic_add_group()</title>
<updated>2023-07-28T20:08:58+00:00</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omp.ru</email>
</author>
<published>2023-07-19T20:22:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b56e23bf0c606b68df2919317f7065dabe3c4e86'/>
<id>urn:sha1:b56e23bf0c606b68df2919317f7065dabe3c4e86</id>
<content type='text'>
pinctrl_generic_add_group() doesn't check the result of radix_tree_insert()
despite they both may return a negative error code.  Linus Walleij said he
has copied the radix tree code from kernel/irq/ where the functions calling
radix_tree_insert() are *void* themselves; I think it makes more sense to
propagate the errors from radix_tree_insert() upstream if we can do that...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.

Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omp.ru&gt;
Link: https://lore.kernel.org/r/20230719202253.13469-2-s.shtylyov@omp.ru
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: remove asm-generic/gpio.h</title>
<updated>2023-03-06T10:33:01+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2023-02-08T15:37:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eccb7a00613c804ec7244676090bf6ee43a23da2'/>
<id>urn:sha1:eccb7a00613c804ec7244676090bf6ee43a23da2</id>
<content type='text'>
The asm-generic/gpio.h file is now always included when
using gpiolib, so just move its contents into linux/gpio.h
with a few minor simplifications.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
</content>
</entry>
</feed>
