<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpio, branch v6.12.98</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.98</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.98'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-24T14:11:49+00:00</updated>
<entry>
<title>gpio: sch: use raw_spinlock_t in the irq startup path</title>
<updated>2026-07-24T14:11:49+00:00</updated>
<author>
<name>Runyu Xiao</name>
<email>runyu.xiao@seu.edu.cn</email>
</author>
<published>2026-07-15T11:15:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a235cec779bb39ec8f961a935b28a2ce278c6c64'/>
<id>urn:sha1:a235cec779bb39ec8f961a935b28a2ce278c6c64</id>
<content type='text'>
[ Upstream commit 286533cb14a3c8a8bd39ff64ea2fc8e1aa0f638b ]

sch_irq_unmask() enables the GPIO IRQ and then updates the controller
state through sch_irq_mask_unmask(), which takes sch-&gt;lock with
spin_lock_irqsave().  The callback can be reached from irq_startup()
while setting up a requested IRQ.  That path is not sleepable, but on
PREEMPT_RT a regular spinlock_t becomes a sleeping lock.

This issue was found by our static analysis tool and then manually
reviewed against the current tree.

The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;
irq_startup() -&gt; sch_irq_unmask() -&gt; sch_irq_mask_unmask() carrier and
used the original spin_lock_irqsave(&amp;sch-&gt;lock) edge.  Lockdep reported:

  BUG: sleeping function called from invalid context
  hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
  sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
  sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
  __setup_irq.constprop.0+0xd/0x30 [vuln_msv]

Convert the SCH controller lock to raw_spinlock_t.  The same lock is
also used by the GPIO direction and value callbacks, but those critical
sections only update MMIO-backed GPIO registers and do not contain
sleepable operations.  Keeping this register lock non-sleeping is
therefore appropriate for the irqchip callbacks and does not change the
GPIO-side locking contract.

Fixes: 7a81638485c1 ("gpio: sch: Add edge event support")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao &lt;runyu.xiao@seu.edu.cn&gt;
Reviewed-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@intel.com&gt;
Link: https://patch.msgid.link/20260617154035.1199948-2-runyu.xiao@seu.edu.cn
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
[ dropped the `return 0;` and kept sch_gpio_set()'s void signature since 6.12 lacks the GPIO setter-return-value conversion ]
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>gpios: palmas: add .get_direction() op</title>
<updated>2026-07-24T14:11:41+00:00</updated>
<author>
<name>Andreas Kemnade</name>
<email>andreas@kemnade.info</email>
</author>
<published>2026-07-04T08:40:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dd9f4b4e163d788fda906f55ac01a2497915ecff'/>
<id>urn:sha1:dd9f4b4e163d788fda906f55ac01a2497915ecff</id>
<content type='text'>
commit db4a79713ed8e252d5e4edf6eaaa80948b6855a2 upstream.

Accessing debug/gpio is quite noisy without a get_direction()
implementation. To calm that down add an implementation.

Fixes: 3d50a2785271 ("gpio: palmas: Add support for Palmas GPIO")
Cc: stable@vger.kernel.org
Reviewed-by: Linus Walleij &lt;linusw@kernel.org&gt;
Signed-off-by: Andreas Kemnade &lt;andreas@kemnade.info&gt;
Link: https://patch.msgid.link/20260704-palmas-getdirection-v2-1-2fd85fee3832@kemnade.info
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>gpio-f7188x: Add support for NCT6126D version B</title>
<updated>2026-07-24T14:11:41+00:00</updated>
<author>
<name>Paul Louvel</name>
<email>paul.louvel@bootlin.com</email>
</author>
<published>2026-06-29T14:07:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=886fa1b7551afd163b0b0e113d3ce18484f7ca45'/>
<id>urn:sha1:886fa1b7551afd163b0b0e113d3ce18484f7ca45</id>
<content type='text'>
commit 9a6c0b6ea12746d50cf53d59a7e05fd83f974bda upstream.

The Nuvoton NCT6126D Super-I/O is available in two hardware revisions.
According to the manufacturer datasheet revision 2.4, version A reports
chip ID 0xD283, while version B reports chip ID 0xD284.

The driver currently only recognizes only the version A ID. Version B
only contains hardware fixes unrelated to the GPIO functionality, so it
can be supported by simply adding its chip ID without any other driver
changes.

Fixes: 3002b8642f01 ("gpio-f7188x: fix chip name and pin count on Nuvoton chip")
Cc: stable@vger.kernel.org

Signed-off-by: Paul Louvel &lt;paul.louvel@bootlin.com&gt;
Link: https://patch.msgid.link/20260629-gpio-f7188x-nct6126d-version-b-v1-1-a06226c02a2d@bootlin.com
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>gpio: tegra: do not call pinctrl for GPIO direction</title>
<updated>2026-07-24T14:11:41+00:00</updated>
<author>
<name>Runyu Xiao</name>
<email>runyu.xiao@seu.edu.cn</email>
</author>
<published>2026-06-19T15:24:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd17c5a1d9f186b57e9e2949be427803b7110a5c'/>
<id>urn:sha1:cd17c5a1d9f186b57e9e2949be427803b7110a5c</id>
<content type='text'>
commit d3e91a95b2b0fc6336dbf3ec90d831a1654d2720 upstream.

tegra_gpio_direction_input() and tegra_gpio_direction_output() already
program the GPIO controller direction registers directly. The additional
pinctrl_gpio_direction_input/output() calls do not add a Tegra pinctrl
operation, because the Tegra pinmux ops provide GPIO request/free
handling but no gpio_set_direction hook.

The extra call still enters the pinctrl core and takes pctldev-&gt;mutex.
Shared GPIO users can call the direction path while holding their
per-line spinlock, so this otherwise redundant pinctrl direction call can
sleep in an atomic context.

This was found by our static analysis tool and then confirmed by manual
review of tegra_gpio_probe(), the Tegra GPIO direction callbacks and the
Tegra pinctrl ops. The reviewed path has a default non-sleeping
struct gpio_chip while the direction callback still enters the pinctrl
mutex path.

A directed runtime validation kept the same non-sleeping chip registration
and drove:

  gpio_shared_proxy_direction_output()
  gpiod_direction_output_raw_commit()
  tegra_gpio_direction_output()
  pinctrl_gpio_direction_output()

Lockdep reported a sleep-in-atomic warning with the shared GPIO spinlock
held and pinctrl_get_device_gpio_range() plus tegra_gpio_direction_output()
on the stack.

Do not mark the whole chip as can_sleep to paper over this: can_sleep
describes whether get()/set() may sleep, and Tegra value access is MMIO.
Remove the redundant pinctrl direction calls and keep pinctrl involvement
in the existing request/free path.

Fixes: 11da90541283 ("gpio: tegra: Fix offset of pinctrl calls")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao &lt;runyu.xiao@seu.edu.cn&gt;
Link: https://patch.msgid.link/20260619152439.1239561-1-runyu.xiao@seu.edu.cn
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>gpio: mvebu: free generic chips on unbind</title>
<updated>2026-07-24T14:11:24+00:00</updated>
<author>
<name>Rosen Penev</name>
<email>rosenp@gmail.com</email>
</author>
<published>2026-07-07T23:23:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3649b04f86b95243fa0c845695051455fa2ba40b'/>
<id>urn:sha1:3649b04f86b95243fa0c845695051455fa2ba40b</id>
<content type='text'>
[ Upstream commit b11c513ad943f35cf5e8007d3a56279c79b7ed4b ]

irq_alloc_domain_generic_chips() allocates generic chip data that must
be freed via irq_domain_remove_generic_chips(). The devres action
mvebu_gpio_remove_irq_domain() only called irq_domain_remove(), which
only frees the generic chips if IRQ_DOMAIN_FLAG_DESTROY_GC is set.
Call irq_domain_remove_generic_chips() explicitly before
irq_domain_remove() instead.

Fixes: 812d47889a8e ("gpio/mvebu: Use irq_domain_add_linear")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev &lt;rosenp@gmail.com&gt;
Link: https://patch.msgid.link/20260707232358.1218077-1-rosenp@gmail.com
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe</title>
<updated>2026-07-24T14:11:20+00:00</updated>
<author>
<name>Vladimir Zapolskiy</name>
<email>vz@kernel.org</email>
</author>
<published>2026-06-30T14:51:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6761e587e68d14d6400876a08a44befbb6afe05e'/>
<id>urn:sha1:6761e587e68d14d6400876a08a44befbb6afe05e</id>
<content type='text'>
[ Upstream commit 8d7e62d5e9b2d2ff146f472a9215d7e29c7e2307 ]

Out of memory situation on driver's probe is expected to be reported to
the driver's framework with a proper -ENOMEM error code.

Fixes: 35570ac6039e ("gpio: add GPIO driver for the Timberdale FPGA")
Signed-off-by: Vladimir Zapolskiy &lt;vz@kernel.org&gt;
Link: https://patch.msgid.link/20260630145148.4081967-1-vz@kernel.org
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: htc-egpio: use managed gpiochip registration</title>
<updated>2026-07-24T14:11:18+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-06-24T13:18:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=131899b8f6db75c29811423a4ee5334b2cc25277'/>
<id>urn:sha1:131899b8f6db75c29811423a4ee5334b2cc25277</id>
<content type='text'>
[ Upstream commit 17326db5f0ab4ec1901e75d052b5ebef486b467f ]

egpio_probe() registers each nested gpio_chip with gpiochip_add_data()
but ignores the return value. If one registration fails, probe still
returns success even though one of the chips was not published to
gpiolib.

Use devm_gpiochip_add_data() and fail probe if any chip registration
fails. This lets devres unwind already registered chips and prevents
the driver from publishing a partially initialized device.

Fixes: a1635b8fe59d ("[ARM] 4947/1: htc-egpio, a driver for GPIO/IRQ expanders with fixed input/output pins")
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20260624131828.94139-1-pengpeng@iscas.ac.cn
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: mvebu: fail probe if gpiochip registration fails</title>
<updated>2026-07-24T14:11:18+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-06-24T13:16:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e75ca5505d99f3a260e8d189068577e1bc2e3a09'/>
<id>urn:sha1:e75ca5505d99f3a260e8d189068577e1bc2e3a09</id>
<content type='text'>
[ Upstream commit 479e91fc92416a4d54d2b3150aa1e4550d9cc759 ]

mvebu_gpio_probe() registers the GPIO chip with
devm_gpiochip_add_data() but ignores the return value. If registration
fails, probe continues and leaves later code operating on a GPIO chip
that was never published to gpiolib.

Return the registration error so the device fails probe cleanly.

Fixes: fefe7b092345 ("gpio: introduce gpio-mvebu driver for Marvell SoCs")
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20260624131645.86884-1-pengpeng@iscas.ac.cn
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: davinci: fix IRQ domain leak on devm_kzalloc failure</title>
<updated>2026-07-24T14:11:15+00:00</updated>
<author>
<name>Qingshuang Fu</name>
<email>fuqingshuang@kylinos.cn</email>
</author>
<published>2026-06-23T02:31:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f560d130a6e9de5b4ab0a9aac0afd631a1a8cc3d'/>
<id>urn:sha1:f560d130a6e9de5b4ab0a9aac0afd631a1a8cc3d</id>
<content type='text'>
[ Upstream commit 4e8eb6952aa6749726c6c3763ae0032a6332c24f ]

In davinci_gpio_irq_setup(), after successfully creating an IRQ domain
with irq_domain_create_legacy(), a subsequent devm_kzalloc() failure
in the bank loop causes the function to return -ENOMEM without
removing the IRQ domain.

Unlike devm-managed resources, irq_domain_create_legacy() does not
auto-clean up on probe failure, so the domain is leaked.

Fix by calling irq_domain_remove() before returning on allocation
failure.

Fixes: b5cf3fd827d2 ("gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip")
Signed-off-by: Qingshuang Fu &lt;fuqingshuang@kylinos.cn&gt;
Link: https://patch.msgid.link/20260623023106.117229-1-fffsqian@163.com
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: mlxbf3: fail probe if gpiochip registration fails</title>
<updated>2026-07-24T14:11:10+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-06-15T09:19:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8667010fc6c4fc05fc40d39c06f3984d9a0d0a9b'/>
<id>urn:sha1:8667010fc6c4fc05fc40d39c06f3984d9a0d0a9b</id>
<content type='text'>
[ Upstream commit 0482862a90169f4daaba0ed31a85d8304bf51e04 ]

mlxbf3_gpio_probe() logs a devm_gpiochip_add_data() failure but still
returns success. That leaves the platform device bound even though the
GPIO chip was not registered.

Return the registration error so probe failure matches the missing
gpiochip state.

Fixes: cd33f216d241 ("gpio: mlxbf3: Add gpio driver support")
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Reviewed-by: Linus Walleij &lt;linusw@kernel.org&gt;
Link: https://patch.msgid.link/20260615091918.43333-1-pengpeng@iscas.ac.cn
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
