* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Viacheslav @ 2026-06-26 7:16 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-gpio, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <d8d407d5-ba6c-4197-9cf0-2fa7e6e17155@samsung.com>
Hi!
26.06.2026 08:54, Marek Szyprowski wrote:
> On 25.06.2026 13:57, Viacheslav Bocharov wrote:
>> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
>> runtime from the underlying chip's can_sleep:
>>
>> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
>> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
...
>>
>> The lock type was added by commit a060b8c511ab ("gpiolib: implement
>> low-level, shared GPIO support"); the sleeping call under it arrived with
>> the proxy driver.
>>
>> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
>> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
>> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
>
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
Thanks!
Best regards
--
Viacheslav Bocharov
^ permalink raw reply
* Re: (subset) [PATCH 0/3] gpio: rockchip: Fix generic IRQ chip leak and modernize resource mapping
From: Bartosz Golaszewski @ 2026-06-26 7:54 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Marco Scardovi
Cc: Bartosz Golaszewski, Heiko Stuebner, Jianqun Xu, linux-gpio,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260607230504.35392-1-scardracs@disroot.org>
On Mon, 08 Jun 2026 01:05:01 +0200, Marco Scardovi wrote:
> This series fixes a generic IRQ chip leak in the gpio-rockchip driver
> and performs two small cleanups to use standard platform device helper APIs.
>
> Patch 1 fixes a leak caused by generic IRQ chips not being removed before
> IRQ domain teardown.
>
> Patch 2 converts register mapping to use devm_platform_ioremap_resource().
>
> [...]
Applied, thanks!
[2/3] gpio: rockchip: use devm_platform_ioremap_resource() to map registers
https://git.kernel.org/brgl/c/c03c6a086d188dc5b52e7db2b2991ecead9bb669
[3/3] gpio: rockchip: use platform_get_irq() to retrieve interrupt
https://git.kernel.org/brgl/c/c2e26f2408226de7464ba4cdcd86827e0a000db9
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: (subset) [PATCH 0/3] gpio: tb10x: W=1 warning fix and style cleanups
From: Bartosz Golaszewski @ 2026-06-26 7:59 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Igor Putko
Cc: Bartosz Golaszewski, linux-gpio, linux-kernel
In-Reply-To: <20260618155626.18751-1-igorpetindev@gmail.com>
On Thu, 18 Jun 2026 18:56:23 +0300, Igor Putko wrote:
> This series fixes a kernel-doc warning in the tb10x GPIO driver
> and addresses two minor checkpatch.pl coding style issues.
>
> Patch 1 fixes the kernel-doc structure formatting.
> Patch 2 replaces bare unsigned with unsigned int.
> Patch 3 removes unnecessary braces from a single-statement block.
>
> [...]
Applied, thanks!
[2/3] gpio: tb10x: use unsigned int instead of bare unsigned
https://git.kernel.org/brgl/c/23cf763ac5d084f9459a10a9fece9cb1ddc023d9
[3/3] gpio: tb10x: remove unnecessary braces
https://git.kernel.org/brgl/c/309f81de06c00c12a41e318633e1d1d0c9d67e2c
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/4] gpio: realtek: Add support for Realtek DHC RTD1625
From: Bartosz Golaszewski @ 2026-06-26 7:59 UTC (permalink / raw)
To: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, mwalle,
andriy.shevchenko, tychang, Yu-Chun Lin
Cc: Bartosz Golaszewski, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, linux-realtek-soc, cy.huang, stanley_chang,
james.tai
In-Reply-To: <20260622092335.1166876-1-eleanor.lin@realtek.com>
On Mon, 22 Jun 2026 17:23:31 +0800, Yu-Chun Lin wrote:
> This series adds GPIO support for the Realtek DHC RTD1625 SoC.
>
> Unlike the existing driver (gpio-rtd.c) which uses shared bank registers,
> the RTD1625 features a per-pin register architecture where each GPIO line
> is managed by its own dedicated 32-bit control register. This distinct
> hardware design requires a new, separate driver.
>
> [...]
Applied, thanks!
[1/4] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
https://git.kernel.org/brgl/c/8f32808e1530b2229e07695fb39c54fee910bd4a
[2/4] gpio: Replace "default y" with "default ARCH_REALTEK" in Kconfig
https://git.kernel.org/brgl/c/b5d23fcdb12972c522e96f90ab48be8a0d971b0e
[3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
https://git.kernel.org/brgl/c/a57e27c43b0315ee86c6896510d69be5257e093e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: mt8516/mt8167: Move compatibles from mt66xx to mt6795
From: Luca Leonardo Scorcia @ 2026-06-26 9:12 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-mediatek, Sean Wang, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260625-unearth-suffering-e2c59d39da0f@spud>
> Usually when making ABI changes because something was inaccurate (but
> not wrong to the point that it didn't work at all) it's possible to
> support both new and old ABIs at the same time because of new properties
> etc. This is a difficult one because it's using the same properties in
> different ways. A new compatible would definitely be required for a
> genuine fresh start while retaining kernel support for the old mechanism
> in this case.
All things considered, the cleanest solution seems to be adding a new
compatible, mark the old one as deprecated and also try to fix the old
driver code. I'll try to do that before submitting again.
Thank you for your help!
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH v11] PCI: Add support for PCIe WAKE# interrupt
From: Bartosz Golaszewski @ 2026-06-26 9:31 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: linux-pm, linux-kernel, linux-pci, linux-gpio, quic_vbadigan,
sherry.sun, driver-core, devicetree, Manivannan Sadhasivam,
Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Bjorn Helgaas, Bartosz Golaszewski,
Linus Walleij, Bartosz Golaszewski, Rob Herring, Saravana Kannan
In-Reply-To: <20260624-wakeirq_support-v11-1-120fbfaebe59@oss.qualcomm.com>
On Wed, 24 Jun 2026 13:25:49 +0200, Krishna Chaitanya Chundru
<krishna.chundru@oss.qualcomm.com> said:
> According to the PCI Express specification (PCIe r7.0, Section 5.3.3.2),
> two link wakeup mechanisms are defined: Beacon and WAKE#. Beacon is a
> hardware-only mechanism and is invisible to software (PCIe r7.0,
> Section 4.2.7.8.1). This change adds support for the WAKE# mechanism
> in the PCI core.
>
> According to the PCIe specification, multiple WAKE# signals can exist in
> a system or each component in the hierarchy could share a single WAKE#
> signal. In configurations involving a PCIe switch, each downstream port
> (DSP) of the switch may be connected to a separate WAKE# line, allowing
> each endpoint to signal WAKE# independently. From figure 5.4 in sec
> 5.3.3.2, WAKE# can also be terminated at the switch itself. Such topologies
> are typically not described in Device Tree, therefore it is out of scope
> for this series.
>
> To support this, the WAKE# should be described in the device tree node of
> the endpoint/bridge. If all endpoints share a single WAKE# line, then each
> endpoint node shall describe the same WAKE# signal or a single WAKE# in
> the Root Port node.
>
> In pci_device_add(), PCI framework will search for the WAKE# in device
> node. Once found, register for the wake IRQ through
> dev_pm_set_dedicated_wake_irq() associates a wakeup IRQ with a device
> and requests it, but the PM core keeps the IRQ disabled by default. The
> IRQ is enabled by the PM core, only when the device is permitted to wake
> the system, i.e. during system suspend and after runtime suspend, and
> only when device wakeup is enabled.
>
> If the same WAKE# GPIO is described in multiple device tree nodes, only the
> first device that successfully registers the wake IRQ will succeed, while
> subsequent registrations may fail. This limitation does not affect
> functional correctness, since WAKE# is only used to bring the link to D0,
> and endpoint-specific wakeup handling is resolved later through
> PME detection (PME_EN is set in suspend path by PCI core by default).
>
> When the wake IRQ fires, the wakeirq handler invokes pm_runtime_resume() to
> bring the device back to an active power state, such as transitioning from
> D3cold to D0. Once the device is active and the link is usable, the
> endpoint may generate a PME, which is then handled by the PCI core through
> PME polling or the PCIe PME service driver to complete the wakeup of the
> endpoint.
>
> WAKE# is added in dts schema and merged based on below links.
>
> Link: https://lore.kernel.org/all/20250515090517.3506772-1-krishna.chundru@oss.qualcomm.com/
> Link: https://github.com/devicetree-org/dt-schema/pull/170
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2] pinctrl: qcom: Avoid assigning unused private context in test cases
From: Bartosz Golaszewski @ 2026-06-26 9:37 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Yuanjie Yang, Sneh Mankad
Cc: Bartosz Golaszewski, linux-arm-msm, linux-gpio, linux-kernel
In-Reply-To: <20260610-tlmm_test_changes-v2-1-f34536da4717@oss.qualcomm.com>
On Wed, 10 Jun 2026 11:46:58 +0530, Sneh Mankad wrote:
> tlmm_test_rising_while_disabled() sets thread_op_remain to 10, but this
> variable is only used by the threaded IRQ handler to control the number
> of GPIO pin toggles. Since tlmm_test_rising_while_disabled() does not
> register a threaded IRQ handler, the assignment is never used.
>
> Similarly, tlmm_test_high() and tlmm_test_low() set intr_op_remain to 9,
> but the variable is used to denote the IRQ handler the number of times
> GPIO signal has to be toggled from the hard IRQ handler.
>
> [...]
Applied, thanks!
[1/1] pinctrl: qcom: Avoid assigning unused private context in test cases
https://git.kernel.org/brgl/c/62a3aa000055efcc86483e8953775943513fe44d
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] gpio: pca9570: Use I2C match data
From: Bartosz Golaszewski @ 2026-06-26 9:37 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Pengpeng Hou
Cc: Bartosz Golaszewski, linux-gpio, linux-kernel
In-Reply-To: <20260624053744.72612-1-pengpeng@iscas.ac.cn>
On Wed, 24 Jun 2026 13:37:44 +0800, Pengpeng Hou wrote:
> The driver stores chip metadata in both the OF match table and the I2C
> id table, but probe currently reads it with device_get_match_data().
> That helper only returns firmware-node match data, so an I2C-id/modalias
> match can leave chip_data NULL before the driver dereferences it to read
> ngpio.
>
> Use i2c_get_match_data() so the I2C id table driver_data is consumed
> when firmware match data is not present.
>
> [...]
Applied, thanks!
[1/1] gpio: pca9570: Use I2C match data
https://git.kernel.org/brgl/c/415c63896b76fd98883e190bc7518383cb01779c
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 0/9] MIPS: TXX9: Legacy GPIO interfaces cleanup
From: Bartosz Golaszewski @ 2026-06-26 9:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-mips, linux-gpio, linux-kernel, Thomas Bogendoerfer,
Linus Walleij, Bartosz Golaszewski, Arnd Bergmann
In-Reply-To: <cover.1782389357.git.geert@linux-m68k.org>
On Thu, 25 Jun 2026 14:19:21 +0200, Geert Uytterhoeven
<geert@linux-m68k.org> said:
> Hi all,
>
> This patch series gets rid of legacy GPIO interface usage on the MIPS
> RBTX4927 development board, preceded and followed by some cleanups.
> No blinky LEDs were harmed during the production of this series.
>
> Thanks for your comments!
>
> Geert Uytterhoeven (9):
> MIPS: TXX9: Remove tx4938_spi_init() and txx9_spi_init()
> MIPS: TXX9: Remove txx9_7segled_*() forward declarations
> MIPS: TXX9: rbtx4927: Use GPIO lookup table for SIO DTR
> MIPS: TXX9: rbtx4927: Use GPIO lookup table for TXx9 LEDs
> MIPS: TXX9: Reduce TXX9_IOCLED_MAXLEDS to 3
> MIPS: TXX9: Use GPIO lookup table for iocled LEDs
> MIPS: TXX9: Drop GPIOLIB_LEGACY select
> MIPS: TXX9: Convert gpio_txx9 to dynamic GPIO base allocation
> MIPS: TXX9: Clean up txx9_iocled_init()
>
> arch/mips/include/asm/txx9/generic.h | 9 +-----
> arch/mips/include/asm/txx9/tx4938.h | 1 -
> arch/mips/include/asm/txx9pio.h | 3 +-
> arch/mips/kernel/gpio_txx9.c | 5 ++-
> arch/mips/txx9/Kconfig | 1 -
> arch/mips/txx9/generic/setup.c | 45 ++++++++++-----------------
> arch/mips/txx9/generic/setup_tx4938.c | 6 ----
> arch/mips/txx9/rbtx4927/setup.c | 36 ++++++++++++++++-----
> 8 files changed, 49 insertions(+), 57 deletions(-)
>
> --
For the series:
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Sashiko sashikos as usual but it points out issues in error paths in legacy
board files so we can safely ignore them.
Bart
^ permalink raw reply
* Re: [PATCH v3] gpio: mvebu: fail probe if gpiochip registration fails
From: Bartosz Golaszewski @ 2026-06-26 9:49 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Arnd Bergmann, Thomas Petazzoni, Jason Cooper, linux-gpio,
linux-kernel, Linus Walleij, Bartosz Golaszewski
In-Reply-To: <20260624131645.86884-1-pengpeng@iscas.ac.cn>
On Wed, 24 Jun 2026 15:16:45 +0200, Pengpeng Hou <pengpeng@iscas.ac.cn> said:
> 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 <pengpeng@iscas.ac.cn>
> ---
> Changes since v2:
> https://lore.kernel.org/all/20260622153137.69065-1-pengpeng@iscas.ac.cn/
> - Add the Fixes tag requested by Bartosz Golaszewski.
Please include the entie changelog with all versions in the future.
Bart
>
> drivers/gpio/gpio-mvebu.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index c030d1f00abc..689dc6354c2d 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -1221,7 +1221,10 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
> BUG();
> }
>
> - devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
> + err = devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
> + if (err)
> + return dev_err_probe(&pdev->dev, err,
> + "failed to register gpiochip\n");
>
> /* Some MVEBU SoCs have simple PWM support for GPIO lines */
> if (IS_REACHABLE(CONFIG_PWM)) {
> --
> 2.50.1 (Apple Git-155)
>
>
^ permalink raw reply
* Re: [PATCH v3] gpio: mvebu: fail probe if gpiochip registration fails
From: Bartosz Golaszewski @ 2026-06-26 9:58 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Pengpeng Hou
Cc: Bartosz Golaszewski, Arnd Bergmann, Thomas Petazzoni,
Jason Cooper, linux-gpio, linux-kernel
In-Reply-To: <20260624131645.86884-1-pengpeng@iscas.ac.cn>
On Wed, 24 Jun 2026 21:16:45 +0800, Pengpeng Hou wrote:
> 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.
>
> [...]
Applied, thanks!
[1/1] gpio: mvebu: fail probe if gpiochip registration fails
https://git.kernel.org/brgl/c/479e91fc92416a4d54d2b3150aa1e4550d9cc759
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3] gpio: htc-egpio: use managed gpiochip registration
From: Bartosz Golaszewski @ 2026-06-26 9:58 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Pengpeng Hou
Cc: Bartosz Golaszewski, Russell King, Philipp Zabel, linux-gpio,
linux-kernel
In-Reply-To: <20260624131828.94139-1-pengpeng@iscas.ac.cn>
On Wed, 24 Jun 2026 21:18:28 +0800, Pengpeng Hou wrote:
> 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.
>
> [...]
Applied, thanks!
[1/1] gpio: htc-egpio: use managed gpiochip registration
https://git.kernel.org/brgl/c/17326db5f0ab4ec1901e75d052b5ebef486b467f
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 00/32] pinctrl: mediatek: Enable module build support for all drivers
From: AngeloGioacchino Del Regno @ 2026-06-26 10:04 UTC (permalink / raw)
To: Justin Yeh, Sean Wang, Linus Walleij, Matthias Brugger
Cc: Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260626040112.2436185-1-justin.yeh@mediatek.com>
On 6/26/26 06:00, Justin Yeh wrote:
> Sorry for the quick v4 - v3 was sent with an incomplete cover letter
> (template placeholders) by mistake. This v4 also unifies MODULE_LICENSE
> to consistently use "GPL v2" across all patches.
>
> This series enables all MediaTek pinctrl drivers to be built as loadable
> kernel modules. This is required for Android GKI (Generic Kernel Image) +
> vendor_dlkm deployments where vendor-specific drivers must be kept separate
> from the GKI vmlinux.
>
> Each patch adds MODULE_LICENSE("GPL v2") and MODULE_DESCRIPTION() macros where
> missing, and changes the Kconfig option from bool to tristate. This allows
> these drivers to be properly packaged as vendor kernel modules while
> maintaining the existing built-in option.
>
The entire series is
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
...but I'm not sure if one commit for each is ok, makes reverting easy but that
may be too much noise. Should Linus ask for joining them all, feel free to still
keep my R-b tag, as I'd be fine with that as well.
Cheers,
Angelo
> Changes in v4:
> * Fix cover letter content (v3 accidentally sent with template placeholders)
> * Unify MODULE_LICENSE to use "GPL v2" consistently across all drivers
> * Update all commit messages to reflect "GPL v2" instead of "GPL"
>
> Changes in v3:
> * Add MODULE_DESCRIPTION() for all drivers (even those that already had MODULE_LICENSE)
> * Update commit messages to reflect that we're adding MODULE_DESCRIPTION too
>
> Changes in v2:
> * Squash MODULE_LICENSE and tristate changes into single patch per driver
> * Extend fix to all MediaTek pinctrl drivers (32 total), not just MT8189
> * Add Android GKI + vendor_dlkm context to cover letter
> * Add MODULE_DESCRIPTION() where it was missing
> * Add Fixes: tags referencing the original commits that added each driver
>
> Justin Yeh (32):
> pinctrl: mediatek: mt8189: Enable module build support
> pinctrl: mediatek: mt6878: Enable module build support
> pinctrl: mediatek: mt6893: Enable module build support
> pinctrl: mediatek: mt7622: Enable module build support
> pinctrl: mediatek: mt7981: Enable module build support
> pinctrl: mediatek: mt7986: Enable module build support
> pinctrl: mediatek: mt7988: Enable module build support
> pinctrl: mediatek: mt8167: Enable module build support
> pinctrl: mediatek: mt8173: Enable module build support
> pinctrl: mediatek: mt8183: Enable module build support
> pinctrl: mediatek: mt8186: Enable module build support
> pinctrl: mediatek: mt8188: Enable module build support
> pinctrl: mediatek: mt8192: Enable module build support
> pinctrl: mediatek: mt8195: Enable module build support
> pinctrl: mediatek: mt8196: Enable module build support
> pinctrl: mediatek: mt8365: Enable module build support
> pinctrl: mediatek: mt8516: Enable module build support
> pinctrl: mediatek: mt2701: Enable module build support
> pinctrl: mediatek: mt7623: Enable module build support
> pinctrl: mediatek: mt7629: Enable module build support
> pinctrl: mediatek: mt8135: Enable module build support
> pinctrl: mediatek: mt8127: Enable module build support
> pinctrl: mediatek: mt7620: Enable module build support
> pinctrl: mediatek: mt7621: Enable module build support
> pinctrl: mediatek: mt76x8: Enable module build support
> pinctrl: mediatek: rt2880: Enable module build support
> pinctrl: mediatek: rt305x: Enable module build support
> pinctrl: mediatek: rt3883: Enable module build support
> pinctrl: mediatek: mt6397: Enable module build support
> pinctrl: mediatek: mt2712: Enable module build support
> pinctrl: mediatek: mt6795: Enable module build support
> pinctrl: mediatek: mt6797: Enable module build support
>
> drivers/pinctrl/mediatek/Kconfig | 64 +++++++++++------------
> drivers/pinctrl/mediatek/pinctrl-mt2701.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt2712.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6397.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6795.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6797.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt6878.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt6893.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt7620.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7621.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7622.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7623.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7629.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt76x8.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7981.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7986.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt7988.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8127.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8135.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8167.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8173.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8183.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8186.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8188.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8189.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8192.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8195.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-mt8196.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8365.c | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt8516.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-rt2880.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-rt305x.c | 3 ++
> drivers/pinctrl/mediatek/pinctrl-rt3883.c | 3 ++
> 33 files changed, 114 insertions(+), 32 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 5/9] MIPS: TXX9: Reduce TXX9_IOCLED_MAXLEDS to 3
From: Philippe Mathieu-Daudé @ 2026-06-26 12:58 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Bogendoerfer, Linus Walleij,
Bartosz Golaszewski, Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel
In-Reply-To: <77535cc848c89d339fc5efe9ce1a30e017164a18.1782389357.git.geert@linux-m68k.org>
On 25/6/26 14:19, Geert Uytterhoeven wrote:
> The number of available GPIOs and LEDs on the TXx9 IOC FPGA depends on
> the platform. Since commit 455481fc9a807798 ("MIPS: Remove TX39XX
> support"), the only remaining platform (rbtx4927) supports just three.
> Hence reduce the maximum number, to reduce allocation size.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> arch/mips/txx9/generic/setup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 2/9] MIPS: TXX9: Remove txx9_7segled_*() forward declarations
From: Philippe Mathieu-Daudé @ 2026-06-26 12:58 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Bogendoerfer, Linus Walleij,
Bartosz Golaszewski, Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel
In-Reply-To: <7f91d0735efee29d6d03fa7ff43eed3c41b5b5ac.1782389357.git.geert@linux-m68k.org>
On 25/6/26 14:19, Geert Uytterhoeven wrote:
> The actual implementation was removed in commit 5a8df9281b052ff3 ("MIPS:
> TXX9: Remove rbtx4939 board support").
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> arch/mips/include/asm/txx9/generic.h | 5 -----
> 1 file changed, 5 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/9] MIPS: TXX9: Remove tx4938_spi_init() and txx9_spi_init()
From: Philippe Mathieu-Daudé @ 2026-06-26 12:58 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Bogendoerfer, Linus Walleij,
Bartosz Golaszewski, Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel
In-Reply-To: <c9a39ce801ab0b6c07717816272255a166790274.1782389357.git.geert@linux-m68k.org>
On 25/6/26 14:19, Geert Uytterhoeven wrote:
> The last user of tx4938_spi_init() was removed in commit
> 21d638ef9483d8cf ("MIPS: TXX9: Remove rbtx4938 board support").
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> arch/mips/include/asm/txx9/generic.h | 1 -
> arch/mips/include/asm/txx9/tx4938.h | 1 -
> arch/mips/txx9/generic/setup.c | 17 -----------------
> arch/mips/txx9/generic/setup_tx4938.c | 6 ------
> 4 files changed, 25 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 0/9] MIPS: TXX9: Legacy GPIO interfaces cleanup
From: Linus Walleij @ 2026-06-26 12:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Bogendoerfer, Bartosz Golaszewski, Arnd Bergmann,
linux-mips, linux-gpio, linux-kernel
In-Reply-To: <cover.1782389357.git.geert@linux-m68k.org>
On Thu, Jun 25, 2026 at 2:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> This patch series gets rid of legacy GPIO interface usage on the MIPS
> RBTX4927 development board, preceded and followed by some cleanups.
> No blinky LEDs were harmed during the production of this series.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Sashiko is asking you to fix the entire universe as usual, I couldn't
care less.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 9/9] MIPS: TXX9: Clean up txx9_iocled_init()
From: Philippe Mathieu-Daudé @ 2026-06-26 13:00 UTC (permalink / raw)
To: Geert Uytterhoeven, Thomas Bogendoerfer, Linus Walleij,
Bartosz Golaszewski, Arnd Bergmann
Cc: linux-mips, linux-gpio, linux-kernel
In-Reply-To: <1b51ebc5e63ab41070e099bcc4ec1e8d9b85add5.1782389357.git.geert@linux-m68k.org>
On 25/6/26 14:19, Geert Uytterhoeven wrote:
> The sole caller already uses dynamic GPIO base allocation, so drop
> support for static allocation.
> While at it, drop the no longer used "lowactive" parameter.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> arch/mips/include/asm/txx9/generic.h | 3 +--
> arch/mips/txx9/generic/setup.c | 12 ++++--------
> arch/mips/txx9/rbtx4927/setup.c | 2 +-
> 3 files changed, 6 insertions(+), 11 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 0/9] MIPS: TXX9: Legacy GPIO interfaces cleanup
From: Geert Uytterhoeven @ 2026-06-26 13:00 UTC (permalink / raw)
To: Linus Walleij
Cc: Thomas Bogendoerfer, Bartosz Golaszewski, Arnd Bergmann,
linux-mips, linux-gpio, linux-kernel
In-Reply-To: <CAD++jLnme9So3j77C9ELdon=4dmGEeBKYj80r2g9MoJXw5XApw@mail.gmail.com>
Hi Linus,
On Fri, 26 Jun 2026 at 14:58, Linus Walleij <linusw@kernel.org> wrote:
> On Thu, Jun 25, 2026 at 2:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > This patch series gets rid of legacy GPIO interface usage on the MIPS
> > RBTX4927 development board, preceded and followed by some cleanups.
> > No blinky LEDs were harmed during the production of this series.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
Thanks!
> Sashiko is asking you to fix the entire universe as usual, I couldn't
> care less.
Feeling lucky for not being CCed by Sashiko ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: spmi-gpio: Add PMG1110 GPIO support
From: Linus Walleij @ 2026-06-26 13:00 UTC (permalink / raw)
To: Fenglin Wu, Bartosz Golaszewski
Cc: linux-arm-msm, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-gpio, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20260610-pmg1110-gpio-v1-2-a9c50cd8b5d9@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 9:05 AM Fenglin Wu <fenglin.wu@oss.qualcomm.com> wrote:
> Add PMG1110 GPIO support with its compatible string and match data.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Acked-by: Linus Walleij <linusw@kernel.org>
Bartosz will queue the patch, I think.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: qcom: sc8280xp: Add missing wakeup entries for GPIO143/151
From: Konrad Dybcio @ 2026-06-26 13:08 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Bartosz Golaszewski
Cc: linux-arm-msm, linux-gpio, linux-kernel, Konrad Dybcio
Pins 143 and 151 were not included in the PDC wakeup map. They are
normally used for PCIe2A and PCIe3a PERST# respectively, so they're
unlikely to be excercised in practice, but still add them for the sake
of completeness.
Fixes: c0e4c71a9e7c ("pinctrl: qcom: Introduce sc8280xp TLMM driver")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
drivers/pinctrl/qcom/pinctrl-sc8280xp.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-sc8280xp.c b/drivers/pinctrl/qcom/pinctrl-sc8280xp.c
index 4056b9fa32f8cb90b6d0b5edc31e189b94f800af..e018bd11626cad722f2e4a142daa0b7f1f4bbffa 100644
--- a/drivers/pinctrl/qcom/pinctrl-sc8280xp.c
+++ b/drivers/pinctrl/qcom/pinctrl-sc8280xp.c
@@ -1881,16 +1881,17 @@ static const struct msm_gpio_wakeirq_map sc8280xp_pdc_map[] = {
{ 126, 200 }, { 127, 225 }, { 128, 262 }, { 129, 201 },
{ 130, 209 }, { 131, 173 }, { 132, 202 }, { 136, 210 },
{ 138, 171 }, { 139, 226 }, { 140, 227 }, { 142, 228 },
- { 144, 229 }, { 145, 230 }, { 146, 231 }, { 148, 232 },
- { 149, 233 }, { 150, 234 }, { 152, 235 }, { 154, 212 },
- { 157, 213 }, { 161, 219 }, { 170, 236 }, { 171, 221 },
- { 174, 222 }, { 175, 237 }, { 176, 223 }, { 177, 170 },
- { 180, 238 }, { 181, 239 }, { 182, 240 }, { 183, 241 },
- { 184, 242 }, { 185, 243 }, { 190, 178 }, { 193, 184 },
- { 196, 185 }, { 198, 186 }, { 200, 174 }, { 201, 175 },
- { 205, 176 }, { 206, 177 }, { 208, 187 }, { 210, 198 },
- { 211, 199 }, { 212, 204 }, { 215, 205 }, { 220, 188 },
- { 221, 194 }, { 223, 195 }, { 225, 196 }, { 227, 197 },
+ { 143, 261 }, { 144, 229 }, { 145, 230 }, { 146, 231 },
+ { 148, 232 }, { 149, 233 }, { 150, 234 }, { 151, 264 },
+ { 152, 235 }, { 154, 212 }, { 157, 213 }, { 161, 219 },
+ { 170, 236 }, { 171, 221 }, { 174, 222 }, { 175, 237 },
+ { 176, 223 }, { 177, 170 }, { 180, 238 }, { 181, 239 },
+ { 182, 240 }, { 183, 241 }, { 184, 242 }, { 185, 243 },
+ { 190, 178 }, { 193, 184 }, { 196, 185 }, { 198, 186 },
+ { 200, 174 }, { 201, 175 }, { 205, 176 }, { 206, 177 },
+ { 208, 187 }, { 210, 198 }, { 211, 199 }, { 212, 204 },
+ { 215, 205 }, { 220, 188 }, { 221, 194 }, { 223, 195 },
+ { 225, 196 }, { 227, 197 },
};
static struct msm_pinctrl_soc_data sc8280xp_pinctrl = {
---
base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
change-id: 20260626-topic-8280_pinctrl_wakeup-04adde61f741
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v4 00/32] pinctrl: mediatek: Enable module build support for all drivers
From: Linus Walleij @ 2026-06-26 13:17 UTC (permalink / raw)
To: Justin Yeh, Luca Leonardo Scorcia
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260626040112.2436185-1-justin.yeh@mediatek.com>
Hi Justin,
thanks for your patches!
On Fri, Jun 26, 2026 at 6:01 AM Justin Yeh <justin.yeh@mediatek.com> wrote:
> Sorry for the quick v4 - v3 was sent with an incomplete cover letter
> (template placeholders) by mistake. This v4 also unifies MODULE_LICENSE
> to consistently use "GPL v2" across all patches.
>
> This series enables all MediaTek pinctrl drivers to be built as loadable
> kernel modules. This is required for Android GKI (Generic Kernel Image) +
> vendor_dlkm deployments where vendor-specific drivers must be kept separate
> from the GKI vmlinux.
>
> Each patch adds MODULE_LICENSE("GPL v2") and MODULE_DESCRIPTION() macros where
> missing, and changes the Kconfig option from bool to tristate. This allows
> these drivers to be properly packaged as vendor kernel modules while
> maintaining the existing built-in option.
Two things to fix:
1. Squash all these 32 patches into one, "one technical step". We don't wanna
have to revery 32 patches, if this doesn't work on one driver it doesn't work
on any driver.
2. Consider this Sashiko report on an unrelated patch by Luca:
https://lore.kernel.org/linux-input/20260621083053.A3B641F000E9@smtp.kernel.org/
----8<----------8<--------8<----------8<--------
[Severity: High]
This is a pre-existing issue, but does mtk_pinctrl_driver in
drivers/pinctrl/mediatek/pinctrl-mt6397.c need a .remove callback or
suppress_bind_attrs set to true to prevent unbinding?
In drivers/pinctrl/mediatek/pinctrl-mtk-common.c:mtk_pctrl_init(), the driver
allocates the pctl and pctl->chip structures using devm_kzalloc() but
registers the GPIO chip using the unmanaged gpiochip_add_data() API:
mtk_pctrl_init() {
...
pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
...
ret = gpiochip_add_data(pctl->chip, pctl);
...
}
If the driver is unbound via sysfs, the devm_ subsystem will free the memory
backing the GPIO chip while it remains registered with the core subsystem.
Could this lead to a use-after-free if the GPIOs are accessed after the
driver is unbound?
----8<----------8<--------8<----------8<--------
Well now we will unbind the driver by rmmod as well, so this needs fixing.
Please prepend a patch fixing this to the series.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: spmi-gpio: Add PMG1110 GPIO support
From: Bartosz Golaszewski @ 2026-06-26 14:44 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-msm, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-gpio, devicetree, linux-kernel,
Konrad Dybcio, Fenglin Wu, Bartosz Golaszewski
In-Reply-To: <CAD++jL=_27BOr28Pi_UqjDpJSuRztYGKO2CXynOvwSVpe1-uBA@mail.gmail.com>
On Fri, 26 Jun 2026 15:00:36 +0200, Linus Walleij <linusw@kernel.org> said:
> On Wed, Jun 10, 2026 at 9:05 AM Fenglin Wu <fenglin.wu@oss.qualcomm.com> wrote:
>
>
>> Add PMG1110 GPIO support with its compatible string and match data.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>
> Acked-by: Linus Walleij <linusw@kernel.org>
>
> Bartosz will queue the patch, I think.
>
> Yours,
> Linus Walleij
>
I will go through the pending patches next week. Thanks.
Bart
^ permalink raw reply
* Re: [PATCH v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-06-26 14:48 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-1-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:16 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> This was reported on Khadas VIM3 and worked around for Amlogic by
> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
> sleeping"), which marked the whole meson controller sleeping. That
> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
> no longer detects devices, because its IRQ-disabled read slot calls the
> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>
> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>
> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
> gating on gpiod_cansleep() change behaviour. No current device needs
> atomic (non-cansleep) value access on a shared GPIO -- every report
> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
> which is what the proxy exists to vote on; bit-banging that needs atomic
> access cannot work through voting anyway. An alternative that keeps
> atomic value access (split locking) is possible but adds a second lock
> and new race windows, so this series takes the simpler mutex-only
> approach.
>
> The two are a unit: patch 2 must not be applied without patch 1,
> otherwise the original VIM3 splat returns on boards that share a meson
> GPIO -- please keep the order. I have not Cc'd stable; I will request
> stable backports separately once both patches have landed.
>
> Changes since v1:
> - gpio: shared-proxy: open-code the descriptor mutex; drop the
> gpio_shared_desc_lock guard and the gpio_shared_lockdep_assert()
> helper, move the mutex rationale to the can_sleep assignment. No
> functional change.
>
> v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-1-v@baodeep.com/
>
> Viacheslav Bocharov (2):
> gpio: shared-proxy: always serialize with a sleeping mutex
> pinctrl: meson: restore non-sleeping GPIO access
>
> drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++----------------
> drivers/gpio/gpiolib-shared.c | 9 +---
> drivers/gpio/gpiolib-shared.h | 28 +-----------
> drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
> 4 files changed, 30 insertions(+), 75 deletions(-)
>
>
> base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
> --
> 2.54.0
>
>
I have no idea what's wrong but I'm still getting two copies of each email
as separate messages to my inbox. I'm not seeing it with anyone else. I think
there's some issue with your setup.
Bart
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-26 15:01 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-2-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:17 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
This looks good to me. Linus: do you want me to take patch 2/2 as well? I'll
send it for v7.2-rc2.
Bart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox