linux-stable.git/drivers/pinctrl, branch linux-6.15.y Linux kernel stable tree pinctrl: stm32: Manage irq affinity settings 2025-08-20T16:36:20+00:00 Cheick Traore cheick.traore@foss.st.com 2025-06-10T14:30:39+00:00 2857da7a0bacc51ba333fc537c778bcde8fa4fcc [ Upstream commit 4c5cc2f65386e22166ce006efe515c667aa075e4 ] Trying to set the affinity of the interrupts associated to stm32 pinctrl results in a write error. Fill struct irq_chip::irq_set_affinity to use the default helper function. Signed-off-by: Cheick Traore <cheick.traore@foss.st.com> Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Link: https://lore.kernel.org/20250610143042.295376-3-antonio.borneo@foss.st.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4c5cc2f65386e22166ce006efe515c667aa075e4 ]

Trying to set the affinity of the interrupts associated to stm32
pinctrl results in a write error.

Fill struct irq_chip::irq_set_affinity to use the default helper
function.

Signed-off-by: Cheick Traore <cheick.traore@foss.st.com>
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Link: https://lore.kernel.org/20250610143042.295376-3-antonio.borneo@foss.st.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinmux: fix race causing mux_owner NULL with active mux_usecount 2025-08-15T10:16:44+00:00 Mukesh Ojha mukesh.ojha@oss.qualcomm.com 2025-07-08T07:58:38+00:00 b7bd6e3971eb7f0e34d2fdce1b18b08094e0c804 [ Upstream commit 0b075c011032f88d1cfde3b45d6dcf08b44140eb ] commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned. Fixes: 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/20250708-pinmux-race-fix-v2-1-8ae9e8a0d1a1@oss.qualcomm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0b075c011032f88d1cfde3b45d6dcf08b44140eb ]

commit 5a3e85c3c397 ("pinmux: Use sequential access to access
desc->pinmux data") tried to address the issue when two client of the
same gpio calls pinctrl_select_state() for the same functionality, was
resulting in NULL pointer issue while accessing desc->mux_owner.
However, issue was not completely fixed due to the way it was handled
and it can still result in the same NULL pointer.

The issue occurs due to the following interleaving:

     cpu0 (process A)                   cpu1 (process B)

      pin_request() {                   pin_free() {

                                         mutex_lock()
                                         desc->mux_usecount--; //becomes 0
                                         ..
                                         mutex_unlock()

  mutex_lock(desc->mux)
  desc->mux_usecount++; // becomes 1
  desc->mux_owner = owner;
  mutex_unlock(desc->mux)

                                         mutex_lock(desc->mux)
                                         desc->mux_owner = NULL;
                                         mutex_unlock(desc->mux)

This sequence leads to a state where the pin appears to be in use
(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can
cause NULL pointer on next pin_request on the same pin.

Ensure that updates to mux_usecount and mux_owner are performed
atomically under the same lock. Only clear mux_owner when mux_usecount
reaches zero and no new owner has been assigned.

Fixes: 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data")
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/20250708-pinmux-race-fix-v2-1-8ae9e8a0d1a1@oss.qualcomm.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: canaan: k230: Fix order of DT parse and pinctrl register 2025-08-15T10:16:41+00:00 Ze Huang huangze@whut.edu.cn 2025-06-23T16:11:14+00:00 02c1deb1bff2b6d242e29a51e56107495979a2b8 [ Upstream commit d94a32ac688f953dc9a9f12b5b4139ecad841bbb ] Move DT parse before pinctrl register. This ensures that device tree parsing is done before calling devm_pinctrl_register() to prevent using uninitialized pin resources. Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Ze Huang <huangze@whut.edu.cn> Link: https://lore.kernel.org/20250624-k230-return-check-v1-2-6b4fc5ba0c41@whut.edu.cn Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d94a32ac688f953dc9a9f12b5b4139ecad841bbb ]

Move DT parse before pinctrl register. This ensures that device tree
parsing is done before calling devm_pinctrl_register() to prevent using
uninitialized pin resources.

Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC")
Reported-by: Yao Zi <ziyao@disroot.org>
Signed-off-by: Ze Huang <huangze@whut.edu.cn>
Link: https://lore.kernel.org/20250624-k230-return-check-v1-2-6b4fc5ba0c41@whut.edu.cn
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: canaan: k230: add NULL check in DT parse 2025-08-15T10:16:40+00:00 Ze Huang huangze@whut.edu.cn 2025-06-23T16:11:13+00:00 b5ae84aeff60b8819e8568ff0c57590caed9e6d3 [ Upstream commit 65bd0be486390fc12a84eafaad78758c5e5a55e6 ] Add a NULL check for the return value of of_get_property() when retrieving the "pinmux" property in the group parser. This avoids a potential NULL pointer dereference if the property is missing from the device tree node. Also fix a typo ("sintenel") in the device ID match table comment, correcting it to "sentinel". Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC") Reported-by: Yao Zi <ziyao@disroot.org> Signed-off-by: Ze Huang <huangze@whut.edu.cn> Link: https://lore.kernel.org/20250624-k230-return-check-v1-1-6b4fc5ba0c41@whut.edu.cn Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 65bd0be486390fc12a84eafaad78758c5e5a55e6 ]

Add a NULL check for the return value of of_get_property() when
retrieving the "pinmux" property in the group parser. This avoids
a potential NULL pointer dereference if the property is missing
from the device tree node.

Also fix a typo ("sintenel") in the device ID match table comment,
correcting it to "sentinel".

Fixes: 545887eab6f6 ("pinctrl: canaan: Add support for k230 SoC")
Reported-by: Yao Zi <ziyao@disroot.org>
Signed-off-by: Ze Huang <huangze@whut.edu.cn>
Link: https://lore.kernel.org/20250624-k230-return-check-v1-1-6b4fc5ba0c41@whut.edu.cn
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: berlin: fix memory leak in berlin_pinctrl_build_state() 2025-08-15T10:16:40+00:00 Yuan Chen chenyuan@kylinos.cn 2025-06-20T01:53:43+00:00 a9596c993b86077ca613c9ea54a79699fbb787ea [ Upstream commit 8f6f303551100291bf2c1e1ccc66b758fffb1168 ] In the original implementation, krealloc() failure handling incorrectly assigned the original memory pointer to NULL after kfree(), causing a memory leak when reallocation failed. Fixes: de845036f997 ("pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/20250620015343.21494-1-chenyuan_fl@163.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8f6f303551100291bf2c1e1ccc66b758fffb1168 ]

In the original implementation, krealloc() failure handling incorrectly
assigned the original memory pointer to NULL after kfree(), causing a
memory leak when reallocation failed.

Fixes: de845036f997 ("pinctrl: berlin: fix error return code of berlin_pinctrl_build_state()")
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
Link: https://lore.kernel.org/20250620015343.21494-1-chenyuan_fl@163.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: sunxi: Fix memory leak on krealloc failure 2025-08-15T10:16:40+00:00 Yuan Chen chenyuan@kylinos.cn 2025-06-20T01:27:08+00:00 b63c0b8746683e4f5c8c14ef3d44a38f942dc2a5 [ Upstream commit e3507c56cbb208d4f160942748c527ef6a528ba1 ] In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize the pinctrl_map array, the function returns -ENOMEM directly without freeing the previously allocated *map buffer. This results in a memory leak of the original kmalloc_array allocation. Fixes: e11dee2e98f8 ("pinctrl: sunxi: Deal with configless pins") Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Link: https://lore.kernel.org/20250620012708.16709-1-chenyuan_fl@163.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e3507c56cbb208d4f160942748c527ef6a528ba1 ]

In sunxi_pctrl_dt_node_to_map(), when krealloc() fails to resize
the pinctrl_map array, the function returns -ENOMEM directly
without freeing the previously allocated *map buffer. This results
in a memory leak of the original kmalloc_array allocation.

Fixes: e11dee2e98f8 ("pinctrl: sunxi: Deal with configless pins")
Signed-off-by: Yuan Chen <chenyuan@kylinos.cn>
Link: https://lore.kernel.org/20250620012708.16709-1-chenyuan_fl@163.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: qcom: msm: mark certain pins as invalid for interrupts 2025-07-17T16:43:47+00:00 Bartosz Golaszewski bartosz.golaszewski@linaro.org 2025-06-12T09:14:48+00:00 97c9c7daeeb00c6e1d5e84084041f79c2d2dce22 commit 93712205ce2f1fb047739494c0399a26ea4f0890 upstream. On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this. Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/20250612091448.41546-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 93712205ce2f1fb047739494c0399a26ea4f0890 upstream.

On some platforms, the UFS-reset pin has no interrupt logic in TLMM but
is nevertheless registered as a GPIO in the kernel. This enables the
user-space to trigger a BUG() in the pinctrl-msm driver by running, for
example: `gpiomon -c 0 113` on RB2.

The exact culprit is requesting pins whose intr_detection_width setting
is not 1 or 2 for interrupts. This hits a BUG() in
msm_gpio_irq_set_type(). Potentially crashing the kernel due to an
invalid request from user-space is not optimal, so let's go through the
pins and mark those that would fail the check as invalid for the irq chip
as we should not even register them as available irqs.

This function can be extended if we determine that there are more
corner-cases like this.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Cc: stable@vger.kernel.org
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/20250612091448.41546-1-brgl@bgdev.pl
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pinctrl: nuvoton: Fix boot on ma35dx platforms 2025-07-17T16:43:46+00:00 Miquel Raynal miquel.raynal@bootlin.com 2025-06-13T18:13:12+00:00 06f2f2402ca21ae6900cc1e326144c1fd138eade commit 46147490b4098e200b7d7d3ac4637a3e4f7b806a upstream. As part of a wider cleanup trying to get rid of OF specific APIs, an incorrect (and partially unrelated) cleanup was introduced. The goal was to replace a device_for_each_chil_node() loop including an additional condition inside by a macro doing both the loop and the check on a single line. The snippet: device_for_each_child_node(dev, child) if (fwnode_property_present(child, "gpio-controller")) continue; was replaced by: for_each_gpiochip_node(dev, child) which expands into: device_for_each_child_node(dev, child) for_each_if(fwnode_property_present(child, "gpio-controller")) This change is actually doing the opposite of what was initially expected, breaking the probe of this driver, breaking at the same time the whole boot of Nuvoton platforms (no more console, the kernel WARN()). Revert these two changes to roll back to the correct behavior. Fixes: 693c9ecd8326 ("pinctrl: nuvoton: Reduce use of OF-specific APIs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/20250613181312.1269794-1-miquel.raynal@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 46147490b4098e200b7d7d3ac4637a3e4f7b806a upstream.

As part of a wider cleanup trying to get rid of OF specific APIs, an
incorrect (and partially unrelated) cleanup was introduced.

The goal was to replace a device_for_each_chil_node() loop including an
additional condition inside by a macro doing both the loop and the
check on a single line.

The snippet:

	device_for_each_child_node(dev, child)
		if (fwnode_property_present(child, "gpio-controller"))
			continue;

was replaced by:

	for_each_gpiochip_node(dev, child)

which expands into:

	device_for_each_child_node(dev, child)
		for_each_if(fwnode_property_present(child, "gpio-controller"))

This change is actually doing the opposite of what was initially
expected, breaking the probe of this driver, breaking at the same time
the whole boot of Nuvoton platforms (no more console, the kernel WARN()).

Revert these two changes to roll back to the correct behavior.

Fixes: 693c9ecd8326 ("pinctrl: nuvoton: Reduce use of OF-specific APIs")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/20250613181312.1269794-1-miquel.raynal@bootlin.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pinctrl: amd: Clear GPIO debounce for suspend 2025-07-17T16:43:39+00:00 Mario Limonciello mario.limonciello@amd.com 2025-06-27T15:01:46+00:00 dce86a4d0d5b9e416b3787d624b711ffb3e03a52 [ Upstream commit 8ff4fb276e2384a87ae7f65f3c28e1e139dbb3fe ] soc-button-array hardcodes a debounce value by means of gpio_keys which uses pinctrl-amd as a backend to program debounce for a GPIO. This hardcoded value doesn't match what the firmware intended to be programmed in _AEI. The hardcoded debounce leads to problems waking from suspend. There isn't appetite to conditionalize the behavior in soc-button-array or gpio-keys so clear it when the system suspends to avoid problems with being able to resume. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Hans de Goede <hansg@kernel.org> Fixes: 5c4fa2a6da7fb ("Input: soc_button_array - debounce the buttons") Link: https://lore.kernel.org/linux-input/mkgtrb5gt7miyg6kvqdlbu4nj3elym6ijudobpdi26gp4xxay5@rsa6ytrjvj2q/ Link: https://lore.kernel.org/linux-input/20250625215813.3477840-1-superm1@kernel.org/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/20250627150155.3311574-1-superm1@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8ff4fb276e2384a87ae7f65f3c28e1e139dbb3fe ]

soc-button-array hardcodes a debounce value by means of gpio_keys
which uses pinctrl-amd as a backend to program debounce for a GPIO.

This hardcoded value doesn't match what the firmware intended to be
programmed in _AEI. The hardcoded debounce leads to problems waking
from suspend. There isn't appetite to conditionalize the behavior in
soc-button-array or gpio-keys so clear it when the system suspends to
avoid problems with being able to resume.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hans de Goede <hansg@kernel.org>
Fixes: 5c4fa2a6da7fb ("Input: soc_button_array - debounce the buttons")
Link: https://lore.kernel.org/linux-input/mkgtrb5gt7miyg6kvqdlbu4nj3elym6ijudobpdi26gp4xxay5@rsa6ytrjvj2q/
Link: https://lore.kernel.org/linux-input/20250625215813.3477840-1-superm1@kernel.org/
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Hans de Goede <hansg@kernel.org>
Link: https://lore.kernel.org/20250627150155.3311574-1-superm1@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
pinctrl: mcp23s08: Reset all pins to input at probe 2025-06-27T10:13:27+00:00 Mike Looijmans mike.looijmans@topic.nl 2025-03-14T15:17:45+00:00 5449fe50035a24aae938caa31423f9016cce1f33 [ Upstream commit 3ede3f8b4b4b399b0ca41e44959f80d5cf84fc98 ] At startup, the driver just assumes that all registers have their default values. But after a soft reset, the chip will just be in the state it was, and some pins may have been configured as outputs. Any modification of the output register will cause these pins to be driven low, which leads to unexpected/unwanted effects. To prevent this from happening, set the chip's IO configuration register to a known safe mode (all inputs) before toggling any other bits. Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Link: https://lore.kernel.org/20250314151803.28903-1-mike.looijmans@topic.nl Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3ede3f8b4b4b399b0ca41e44959f80d5cf84fc98 ]

At startup, the driver just assumes that all registers have their
default values. But after a soft reset, the chip will just be in the
state it was, and some pins may have been configured as outputs. Any
modification of the output register will cause these pins to be driven
low, which leads to unexpected/unwanted effects. To prevent this from
happening, set the chip's IO configuration register to a known safe
mode (all inputs) before toggling any other bits.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Link: https://lore.kernel.org/20250314151803.28903-1-mike.looijmans@topic.nl
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>