* [PATCH 6.12.y 1/3] gpiolib: Extract gpiochip_choose_fwnode() for wider use
From: Quentin Schulz @ 2026-06-18 16:02 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Greg Kroah-Hartman
Cc: linux-gpio, linux-kernel, Bartosz Golaszewski, Quentin Schulz,
Andy Shevchenko, Mathieu Dubois-Briand
In-Reply-To: <20260618-6-12-cve-2026-31732-v1-0-7ca0d0b906b0@cherry.de>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit 375790f18396b2ba706e031b150c58cd37b45a11 ]
Extract gpiochip_choose_fwnode() for the future use in another function.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Link: https://lore.kernel.org/r/20250213195621.3133406-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Stable-dep-of: 16fdabe143fc ("gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
drivers/gpio/gpiolib.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 5c8cd81656963..d48a57b899f79 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -883,6 +883,21 @@ void *gpiochip_get_data(struct gpio_chip *gc)
}
EXPORT_SYMBOL_GPL(gpiochip_get_data);
+/*
+ * If the calling driver provides the specific firmware node,
+ * use it. Otherwise use the one from the parent device, if any.
+ */
+static struct fwnode_handle *gpiochip_choose_fwnode(struct gpio_chip *gc)
+{
+ if (gc->fwnode)
+ return gc->fwnode;
+
+ if (gc->parent)
+ return dev_fwnode(gc->parent);
+
+ return NULL;
+}
+
int gpiochip_get_ngpios(struct gpio_chip *gc, struct device *dev)
{
u32 ngpios = gc->ngpio;
@@ -942,14 +957,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
gc->gpiodev = gdev;
gpiochip_set_data(gc, data);
- /*
- * If the calling driver did not initialize firmware node,
- * do it here using the parent device, if any.
- */
- if (gc->fwnode)
- device_set_node(&gdev->dev, gc->fwnode);
- else if (gc->parent)
- device_set_node(&gdev->dev, dev_fwnode(gc->parent));
+ device_set_node(&gdev->dev, gpiochip_choose_fwnode(gc));
gdev->id = ida_alloc(&gpio_ida, GFP_KERNEL);
if (gdev->id < 0) {
--
2.54.0
^ permalink raw reply related
* [PATCH 6.12.y 2/3] gpiolib: Remove redundant assignment of return variable
From: Quentin Schulz @ 2026-06-18 16:02 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Greg Kroah-Hartman
Cc: linux-gpio, linux-kernel, Bartosz Golaszewski, Quentin Schulz,
Andy Shevchenko
In-Reply-To: <20260618-6-12-cve-2026-31732-v1-0-7ca0d0b906b0@cherry.de>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[ Upstream commit 550300b9a295a591e0721a31f8c964a4bc08d51c ]
In some functions the returned variable is assigned to 0 and then
reassigned to the actual value. Remove redundant assignments.
In one case make it more clear that the assignment is not needed.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250416095645.2027695-9-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Stable-dep-of: 16fdabe143fc ("gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
drivers/gpio/gpiolib.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d48a57b899f79..97a32e6f901fc 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -939,7 +939,7 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
struct gpio_device *gdev;
unsigned int desc_index;
int base = 0;
- int ret = 0;
+ int ret;
/*
* First: allocate and populate the internal stat container, and
@@ -959,11 +959,10 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
device_set_node(&gdev->dev, gpiochip_choose_fwnode(gc));
- gdev->id = ida_alloc(&gpio_ida, GFP_KERNEL);
- if (gdev->id < 0) {
- ret = gdev->id;
+ ret = ida_alloc(&gpio_ida, GFP_KERNEL);
+ if (ret < 0)
goto err_free_gdev;
- }
+ gdev->id = ret;
ret = dev_set_name(&gdev->dev, GPIOCHIP_NAME "%d", gdev->id);
if (ret)
@@ -2882,7 +2881,7 @@ EXPORT_SYMBOL_GPL(gpiod_direction_output);
*/
int gpiod_enable_hw_timestamp_ns(struct gpio_desc *desc, unsigned long flags)
{
- int ret = 0;
+ int ret;
VALIDATE_DESC(desc);
@@ -2915,7 +2914,7 @@ EXPORT_SYMBOL_GPL(gpiod_enable_hw_timestamp_ns);
*/
int gpiod_disable_hw_timestamp_ns(struct gpio_desc *desc, unsigned long flags)
{
- int ret = 0;
+ int ret;
VALIDATE_DESC(desc);
--
2.54.0
^ permalink raw reply related
* [PATCH 6.12.y 0/3] gpiolib: backport 16fdabe143fc
From: Quentin Schulz @ 2026-06-18 16:02 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Greg Kroah-Hartman
Cc: linux-gpio, linux-kernel, Bartosz Golaszewski, Quentin Schulz,
Andy Shevchenko, Mathieu Dubois-Briand, Tzung-Bi Shih, stable,
Linus Walleij, Bartosz Golaszewski
Backport 16fdabe143fc ("gpio: Fix resource leaks on errors in
gpiochip_add_data_with_key()") to 6.12.y. To make the git diff more
similar with the upstream commit, also backport 375790f18396 ("gpiolib:
Extract gpiochip_choose_fwnode() for wider use") and 550300b9a295
("gpiolib: Remove redundant assignment of return variable").
The changes between 16fdabe143fc and the third patch of this series is
(according to git-range-diff):
"""
## drivers/gpio/gpiolib.c ##
@@ drivers/gpio/gpiolib.c: static const struct device_type gpio_dev_type = {
@@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, voi
+ }
+
+ gdev->can_sleep = gc->can_sleep;
-+ rwlock_init(&gdev->line_state_lock);
-+ RAW_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
++ BLOCKING_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
+ BLOCKING_INIT_NOTIFIER_HEAD(&gdev->device_notifier);
+#ifdef CONFIG_PINCTRL
+ INIT_LIST_HEAD(&gdev->pin_ranges);
@@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, voi
- gdev->ngpio = gc->ngpio;
- gdev->can_sleep = gc->can_sleep;
-
-- rwlock_init(&gdev->line_state_lock);
-- RAW_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
+- BLOCKING_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
- BLOCKING_INIT_NOTIFIER_HEAD(&gdev->device_notifier);
-
- ret = init_srcu_struct(&gdev->srcu);
@@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, voi
@@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
ret = gpiodev_add_to_list_unlocked(gdev);
if (ret) {
- gpiochip_err(gc, "GPIO integer space overlap, cannot add chip\n");
+ chip_err(gc, "GPIO integer space overlap, cannot add chip\n");
- goto err_cleanup_desc_srcu;
+ goto err_put_device;
}
"""
s/gpiochip_err/chip_err/ aside, the rest of the diff comes from feature
commits which do not fit the rules for backporting to stable.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Andy Shevchenko (2):
gpiolib: Extract gpiochip_choose_fwnode() for wider use
gpiolib: Remove redundant assignment of return variable
Tzung-Bi Shih (1):
gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()
drivers/gpio/gpiolib.c | 156 +++++++++++++++++++++++++------------------------
1 file changed, 79 insertions(+), 77 deletions(-)
---
base-commit: 1d3a00d3bacff25652c96e1527610c69e91f7c38
change-id: 20260618-6-12-cve-2026-31732-63076d516720
Best regards,
--
Quentin Schulz <quentin.schulz@cherry.de>
^ permalink raw reply
* [PATCH 3/3] gpio: tb10x: remove unnecessary braces
From: Igor Putko @ 2026-06-18 15:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio, linux-kernel, Igor Putko
In-Reply-To: <20260618155626.18751-3-igorpetindev@gmail.com>
Fix the checkpatch.pl warning by removing unnecessary braces from
a single-statement if-block in tb10x_gpio_probe().
Signed-off-by: Igor Putko <igorpetindev@gmail.com>
---
drivers/gpio/gpio-tb10x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-tb10x.c b/drivers/gpio/gpio-tb10x.c
index d30524dbc841..7fb8e6223bd1 100644
--- a/drivers/gpio/gpio-tb10x.c
+++ b/drivers/gpio/gpio-tb10x.c
@@ -167,9 +167,8 @@ static int tb10x_gpio_probe(struct platform_device *pdev)
tb10x_gpio->domain = irq_domain_create_linear(dev_fwnode(dev),
tb10x_gpio->chip.gc.ngpio,
&irq_generic_chip_ops, NULL);
- if (!tb10x_gpio->domain) {
+ if (!tb10x_gpio->domain)
return -ENOMEM;
- }
ret = irq_alloc_domain_generic_chips(tb10x_gpio->domain,
tb10x_gpio->chip.gc.ngpio, 1, tb10x_gpio->chip.gc.label,
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] gpio: tb10x: use unsigned int instead of bare unsigned
From: Igor Putko @ 2026-06-18 15:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio, linux-kernel, Igor Putko
In-Reply-To: <20260618155626.18751-2-igorpetindev@gmail.com>
Fix the checkpatch.pl warning by using 'unsigned int' instead of
the bare use of 'unsigned' for the offset parameter in
tb10x_gpio_to_irq().
Signed-off-by: Igor Putko <igorpetindev@gmail.com>
---
drivers/gpio/gpio-tb10x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-tb10x.c b/drivers/gpio/gpio-tb10x.c
index 705bfd80a8d0..d30524dbc841 100644
--- a/drivers/gpio/gpio-tb10x.c
+++ b/drivers/gpio/gpio-tb10x.c
@@ -51,7 +51,7 @@ static inline u32 tb10x_reg_read(struct tb10x_gpio *gpio, unsigned int offs)
return ioread32(gpio->base + offs);
}
-static int tb10x_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int tb10x_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
{
struct tb10x_gpio *tb10x_gpio = gpiochip_get_data(chip);
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] gpio: tb10x: fix struct tb10x_gpio kernel-doc
From: Igor Putko @ 2026-06-18 15:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio, linux-kernel, Igor Putko
In-Reply-To: <20260618155626.18751-1-igorpetindev@gmail.com>
Fix build warning by adding the missing structure name and
description to the kernel-doc comment block.
Signed-off-by: Igor Putko <igorpetindev@gmail.com>
---
drivers/gpio/gpio-tb10x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-tb10x.c b/drivers/gpio/gpio-tb10x.c
index 3c8fd322a713..705bfd80a8d0 100644
--- a/drivers/gpio/gpio-tb10x.c
+++ b/drivers/gpio/gpio-tb10x.c
@@ -33,6 +33,7 @@
/**
+ * struct tb10x_gpio - TB10x GPIO controller structure
* @base: register base address
* @domain: IRQ domain of GPIO generated interrupts managed by this controller
* @irq: Interrupt line of parent interrupt controller
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] gpio: tb10x: W=1 warning fix and style cleanups
From: Igor Putko @ 2026-06-18 15:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio, linux-kernel, Igor Putko
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.
Igor Putko (3):
gpio: tb10x: fix struct tb10x_gpio kernel-doc
gpio: tb10x: use unsigned int instead of bare unsigned
gpio: tb10x: remove unnecessary braces
drivers/gpio/gpio-tb10x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: Question: pinctrl-backed GPIO set_config and gpio_chip::can_sleep
From: Runyu Xiao @ 2026-06-18 15:10 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Walleij, Bartosz Golaszewski, Ludovic Desroches,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Antonio Borneo,
Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, linux-arm-kernel, linux-gpio, linux-stm32,
linux-sunxi, linux-kernel, jianhao.xu, runyu.xiao
In-Reply-To: <CAD++jLmW3vgTFryRAL24x2TbgbR1tbhjw-nFFH3askoZfSibaQ@mail.gmail.com>
Hi,
Thanks for checking this.
I agree that marking these memory-mapped controllers as can_sleep is too
broad if the only sleepable part is the pinctrl range lookup. That would
make consumers treat otherwise MMIO-backed get/set paths as sleepable,
which is not the contract I want to change.
I will hold back the at91-pio4/stm32/sunxi can_sleep series and look at
the pinctrl core direction instead, specifically whether
pinctrldev_list_mutex can be replaced by a non-sleeping lock for
pinctrl_get_device_gpio_range(). That should also line up with the GPIO
direction callback case discussed in the other thread.
Thanks,
Runyu
^ permalink raw reply
* Re: Question: GPIO direction callbacks calling pinctrl in atomic paths
From: Runyu Xiao @ 2026-06-18 15:08 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Walleij, Bartosz Golaszewski, Thierry Reding,
Jonathan Hunter, Robert Jarzmik, linux-gpio, linux-tegra,
linux-kernel, jianhao.xu, runyu.xiao
In-Reply-To: <CAD++jLkL+WV+WYCy7YsQ6n8ZQH27gLHQKf+-CYiV3GU=dbgcUQ@mail.gmail.com>
Hi,
Thanks for checking.
Thierry, thanks for confirming that Tegra does not currently provide a
gpio_set_direction callback. I agree with your concern: even if removing
the call is technically safe for the current Tegra pinctrl implementation,
it may be conceptually cleaner for the GPIO driver to keep delegating the
direction request to pinctrl.
Linus, yes, the mutex I am hitting is the pinctrl device list mutex taken
while resolving the GPIO range. If that lock can be made non-sleeping as
you suggested in the other thread, then this class of direction-path
warnings should be better handled in the pinctrl core instead of by
removing pinctrl_gpio_direction_*() calls from individual GPIO drivers.
I will hold back the PXA/Tegra driver-local patches for now and first
look at whether the pinctrl core locking change covers this direction
callback case as well.
Thanks,
Runyu
^ permalink raw reply
* Re: [PATCH v2] serial: max310x: implement gpio_chip::get_direction()
From: Hugo Villeneuve @ 2026-06-18 14:56 UTC (permalink / raw)
To: Tapio Reijonen
Cc: Greg Kroah-Hartman, Jiri Slaby, Linus Walleij,
Bartosz Golaszewski, Alexander Shiyan, linux-kernel, linux-serial,
linux-gpio
In-Reply-To: <20260615-b4-serial-max310x-gpio-get-direction-v2-1-4704ba2b181a@vaisala.com>
On Mon, 15 Jun 2026 06:38:40 +0000
Tapio Reijonen <tapio.reijonen@vaisala.com> wrote:
> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even when the direction is tracked in
> software. The GPIO core emits a warning when the callback is missing
> and a user reads the direction of a line, e.g. via
> /sys/kernel/debug/gpio.
>
> The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit
> selects output), which the existing direction_input/output callbacks
> already program, so the current direction can be read back directly.
>
> Fixes: f65444187a66 ("serial: New serial driver MAX310X")
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
> ---
> Found and HW-tested on an i.MX6 SoloX board with a MAX14830 over SPI:
> without this, "cat /sys/kernel/debug/gpio" triggers the gpiolib.c:429
> WARNING (tainting the kernel W) on each queried MAX14830 line; with it
> applied the lines report their in/out direction and the WARNING is gone.
> ---
> Changes in v2:
> - Address Hugo Villeneuve's review: use BIT(offset % 4) and put the
> return statement on a single line.
> - Rebase onto v7.1-rc7.
> - Link to v1: https://lore.kernel.org/r/20260602-b4-serial-max310x-gpio-get-direction-v1-1-23bf84e8ee14@vaisala.com
> ---
Reviewed-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> drivers/tty/serial/max310x.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> index ac7d3f197c3a5ce3531d5607f48e21a807314021..09b9ab57d2b4479da90fba178b093008f4b57bb9 100644
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c
> @@ -1212,6 +1212,17 @@ static int max310x_gpio_set(struct gpio_chip *chip, unsigned int offset,
> return 0;
> }
>
> +static int max310x_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct max310x_port *s = gpiochip_get_data(chip);
> + struct uart_port *port = &s->p[offset / 4].port;
> + unsigned int val;
> +
> + val = max310x_port_read(port, MAX310X_GPIOCFG_REG);
> +
> + return val & BIT(offset % 4) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
> +}
> +
> static int max310x_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
> {
> struct max310x_port *s = gpiochip_get_data(chip);
> @@ -1421,6 +1432,7 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
> s->gpio.owner = THIS_MODULE;
> s->gpio.parent = dev;
> s->gpio.label = devtype->name;
> + s->gpio.get_direction = max310x_gpio_get_direction;
> s->gpio.direction_input = max310x_gpio_direction_input;
> s->gpio.get = max310x_gpio_get;
> s->gpio.direction_output= max310x_gpio_direction_output;
>
> ---
> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> change-id: 20260602-b4-serial-max310x-gpio-get-direction-b10ee5be4f24
>
> Best regards,
> --
> Tapio Reijonen <tapio.reijonen@vaisala.com>
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
From: Runyu Xiao @ 2026-06-18 14:49 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Mark Brown
Cc: Herve Codina, Viresh Kumar, Viresh Kumar, Linus Walleij,
Clark Williams, Steven Rostedt, linux-arm-kernel, soc, linux-gpio,
linux-rt-devel, linux-kernel, jianhao.xu, runyu.xiao
In-Reply-To: <20260618081554.zifCwv4I@linutronix.de>
Hi,
Thanks everyone for the feedback.
I will not send the irq_bus_sync_unlock/shadow-state patch for now. From
Sebastian's comments, it sounds like the more important question is
whether this should be handled at the regmap locking/cache level, or by
using a raw lock only where the regmap path is known to be safe.
Herve, your point about other GPIO controllers is fair. I should not
treat PLGPIO as special without checking the wider pattern. I will look
at other irq_enable/irq_disable users that combine irqchip callbacks,
driver spinlocks and regmap_update_bits(), and compare whether they are
using MMIO/flat cache/raw regmap locking or a sleepable regmap path.
For the current PLGPIO draft, I will hold it back until I can answer
whether the right fix belongs in this driver or in the common regmap/GPIO
pattern.
Thanks,
Runyu
^ permalink raw reply
* Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
From: Andy Shevchenko @ 2026-06-18 14:35 UTC (permalink / raw)
To: Basavaraj Natikar
Cc: Marco Scardovi, w_armin, brgl, linusw, linux-acpi, linux-gpio,
linux-kernel, mario.limonciello, westeri
In-Reply-To: <b259a3a3-0440-4da6-a3bb-d840f5242ce2@amd.com>
On Thu, Jun 18, 2026 at 06:46:28PM +0530, Basavaraj Natikar wrote:
> On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> > On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
...
> > I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from acpidump.
> > You can find the raw acpidump.out and the decompiled ASL tables in the
> > following Google Drive folder:
> > https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc?usp=drive_link
> >
> > As far as I can see/understand there is no _DSM method defined under the
> > GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
> >
> > Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> > pin 24 (0x18) are defined as:
> >
> > GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
> > "\\_SB.GPIO", 0x00, ResourceConsumer, ,
> > )
> > {
> > 0x0015 // Pin 21 (Touchpad attention line)
> > }
> >
> > When triggered, they evaluate the _EVT method which calls:
> > Case (0x15)
> > {
> > \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> > }
> >
> > Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and ATKM/ADTM,
> > which stalls synchronously for ~36 seconds when executed during the probe path at
> > boot time.
>
> I traced the _EVT for pin 21 through the dumps:
>
> _EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the Else branch:
> M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change" to the dGPU, then
> ATKM(0xC0)/ADTM().
>
> So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the touchpad —
> the earlier "touchpad" characterization is incorrect. The touchpad
> (TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in its _CRS on a
> different line (pin 0x08, Level/ActiveLow).
>
> The ~36 s stall is consistent with these synchronous MMIO reads + dGPU notify
> \running in the boot probe path while the GPU isn't ready
> (no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
> confirm the exact blocking access).
> Either way, running this AML synchronously at boot is the firmware issue
> the no_edge_events_on_boot quirk works around.
>
> Could you update the commit message accordingly — in particular, drop the
> "touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not the touchpad?
Thanks for the details! The crucial and most important question here, is AMD
going to push OEM(s) to fix firmware accordingly?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: Question: GPIO direction callbacks calling pinctrl in atomic paths
From: Linus Walleij @ 2026-06-18 13:25 UTC (permalink / raw)
To: Runyu Xiao
Cc: Linus Walleij, Bartosz Golaszewski, Robert Jarzmik,
Thierry Reding, Jonathan Hunter, linux-gpio, linux-tegra,
linux-kernel, jianhao.xu
In-Reply-To: <20260618030609.958831-1-runyu.xiao@seu.edu.cn>
Hi Runyu,
thanks for your report!
On Thu, Jun 18, 2026 at 5:11 AM Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
> The class of path we looked at is:
>
> gpiod_direction_output_raw_commit()
> -> <driver>_gpio_direction_output()
> -> pinctrl_gpio_direction_output()
> -> pinctrl_get_device_gpio_range()
> -> mutex_lock(&pctldev->mutex)
Again that is mutex_lock(&pinctrldev_list_mutex); is it not?
If we go with my suggestion in the previous report to just
replace this mutex with a spinlock, I think this issue will
also be solved.
Am I right?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 0/1] gpiolib: acpi: Add quirk for ASUS ROG Strix G16 G614 series
From: Basavaraj Natikar @ 2026-06-18 13:16 UTC (permalink / raw)
To: Marco Scardovi, w_armin
Cc: andriy.shevchenko, brgl, linusw, linux-acpi, linux-gpio,
linux-kernel, mario.limonciello, westeri
In-Reply-To: <20260617231428.96076-1-scardracs@disroot.org>
hi
On 6/18/2026 4:44 AM, Marco Scardovi wrote:
> [You don't often get email from scardracs@disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Armin,
>
> On Wed, Jun 17, 2026 at 10:33 PM, Armin Wolf wrote:
>> could you share the output of "acpidump" on your device? I suspect that Asus
>> uses a _DSM control method to tell Windows to invert the polarity inside the
>> ActiveBoth check.
>>
> I have extracted and decompiled the ACPI tables (DSDT and SSDTs) from acpidump.
> You can find the raw acpidump.out and the decompiled ASL tables in the
> following Google Drive folder:
> https://drive.google.com/drive/folders/1aTqLAnUhrTsPdpA8tfOFyRopG3P3DGnc?usp=drive_link
>
> As far as I can see/understand there is no _DSM method defined under the
> GPIO controller device (AMDI0030) or the \_SB.GPIO scope.
>
> Under the _AEI method (defined in SSDT9 line 188-193), pin 21 (0x15) and
> pin 24 (0x18) are defined as:
>
> GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullNone, 0x0000,
> "\\_SB.GPIO", 0x00, ResourceConsumer, ,
> )
> {
> 0x0015 // Pin 21 (Touchpad attention line)
> }
>
> When triggered, they evaluate the _EVT method which calls:
> Case (0x15)
> {
> \_SB.PCI0.SBRG.HNC0 (0x15, Zero)
> }
>
> Since Arg1 is Zero, HNC0 executes the Else branch, invoking M009 and ATKM/ADTM,
> which stalls synchronously for ~36 seconds when executed during the probe path at
> boot time.
I traced the _EVT for pin 21 through the dumps:
_EVT(0x15) → \_SB.PCI0.SBRG.HNC0(0x15, Zero). With Arg1==0 it takes the Else branch:
M009(), then Notify(^^GPP0.PEGP, 0x81) "Information Change" to the dGPU, then
ATKM(0xC0)/ADTM().
So this _AEI event is dGPU/graphics‑related (it notifies PEGP), not the touchpad —
the earlier "touchpad" characterization is incorrect. The touchpad
(TPD0, _HID "ASUE1416", _CID "PNP0C50") has its own GpioInt() in its _CRS on a
different line (pin 0x08, Level/ActiveLow).
The ~36 s stall is consistent with these synchronous MMIO reads + dGPU notify
\running in the boot probe path while the GPU isn't ready
(no explicit Sleep in the path; a trace_method_name on HNC0/M049 would
confirm the exact blocking access).
Either way, running this AML synchronously at boot is the firmware issue
the no_edge_events_on_boot quirk works around.
Could you update the commit message accordingly — in particular, drop the
"touchpad" wording, since pin 21's _AEI event is the dGPU notify path, not the touchpad?
Thanks,
--
Basavaraj
> Thanks,
> Marco
^ permalink raw reply
* Re: Question: pinctrl-backed GPIO set_config and gpio_chip::can_sleep
From: Linus Walleij @ 2026-06-18 13:15 UTC (permalink / raw)
To: Runyu Xiao
Cc: Linus Walleij, Bartosz Golaszewski, Ludovic Desroches,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Antonio Borneo,
Maxime Coquelin, Alexandre Torgue, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, linux-arm-kernel, linux-gpio, linux-stm32,
linux-sunxi, linux-kernel, jianhao.xu
In-Reply-To: <20260618053650.4053352-1-runyu.xiao@seu.edu.cn>
Hi Runyu,
thanks for your analysis!
On Thu, Jun 18, 2026 at 7:42 AM Runyu Xiao <runyu.xiao@seu.edu.cn> wrote:
> The path we are concerned about is:
>
> gpiod_set_config()
> -> gpio_do_set_config()
> -> gpiochip_generic_config()
> -> pinctrl_gpio_set_config()
> -> pinctrl_get_device_gpio_range()
> -> mutex_lock(&pctldev->mutex)
That would be mutex_lock(&pinctrldev_list_mutex); would it not?
> If gpiod_cansleep() returns false, a GPIO forwarder or another consumer
> can choose an atomic carrier and call gpiod_set_config() while holding a
> spinlock.
I see the problem.
> The local draft I am considering marks only these controllers as
> sleeping:
>
> pinctrl: at91-pio4: mark the GPIO controller as sleeping
> pinctrl: stm32: mark the GPIO controller as sleeping
> pinctrl: sunxi: mark the GPIO controller as sleeping
>
> The reason is that all three expose gpiochip_generic_config() and can
> therefore reach the pinctrl mutex from the GPIO set_config path, while
> their current gpio_chip registration does not set can_sleep.
But that's not the right solution is it? These controllers can probably
just write a register and be done with it, they all look like they are
memory-mapped? That means we introduce sleep where not needed.
Can we simply replace pinctrldev_list_mutex with a spinlock?
The list isn't gonna be huge and all in-memory anyway.
If it takes too much time we need to think about putting the
ranges in a better data structure such as the maple tree.
mutex_lock(&pinctrldev_list_mutex); could then be turned
into spinlock_irqsave() or even better
guard(spinlock_irqsave)(&pinctrldev_list_lock) in
pinctrl_get_device_gpio_range().
This would mean we just take two different spinlocks in seqence
and save state in each so it should work just fine.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] pin control changes for the v7.2 kernel cycle
From: Linus Walleij @ 2026-06-18 13:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux pin control, LKML, Bartosz Golaszewski, Conor Dooley
Hi Linus,
here is the bulk of pin control changes for the v7.2 kernel.
There will be conflicts! Git will fix most of them but a particularly
hairy hunk will
appear in drivers/pinctrl/qcom/pinctrl-eliza.c.
This appears because fixes were merged into the driver that clash with some
new stuff for v7.2. Such things happen.
I have resolved it manually for linux-next so the solution is there,
essentially it's
some tracedata entry that is renamed traceclk in my branch, I think you can
spot it pretty easily.
Other than that it should be smooth sailing, the changes are big for this
subsystem this time around.
Please pull it in!
Yours,
Linus Walleij
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/pinctrl-v7.2-1
for you to fetch changes up to 8b2c4f88c6ee86efdbc81bed1684e13e2efebd53:
pinctrl: Export pinctrl_get_group_selector() (2026-06-15 15:01:15 +0200)
----------------------------------------------------------------
Pin control changes for the v7.2 kernel cycle:
Core changes:
- Add new generic callbacks to populate per-pin pin controllers creating
groups and functions from the device tree building out
pinctrl_generic_to_map() and move the Spacemit driver over to use this.
- Generic board-level pin control driver using the mux framework.
New drivers:
- Amlogic (meson) A9 SoC pin controller.
- Aspeed AST2700 SoC0 and SoC1 pin controllers.
- nVidia Tegra264 pin controller.
- nVidia Tegra238 pin controller.
- Qualcomm Nord TLMM pin controller.
- Qualcomm Shikra TLMM pin controller.
- Qualcomm SM6350 LPASS LPI pin controller.
- Qualcomm IPQ9650 TLMM pin controller.
- Renesas RZ/G3L SoC pin controller.
- UltraRISC DP1000 pin controller.
Improvements:
- Handle pull up/pull down properly in the Renesas RZG2L driver.
- Fix up nVidia Tegra 234 DT bindings.
- Fix up pin definitions in the Qualcomm Eliza driver.
- Qualcomm PM8010 GPIO support in the PM8010 pin controller.
- Qualcomm SM6115 EGPIO support in the SM6115 pin controller.
- Switch Qualcomm LPASS LPI drivers to use runtime PM for power management.
- Clean up the Qualcomm Kconfig business a bit to include the necessary
drivers for each subarch.
- Fix output glitch in the Amlogic (meson) A4 pin controller.
- Move the Airoha driver from the Mediatek directory to its own directory.
It is too different from other Mediatek hardware.
- A slew of fixes to the Airoha AN7581 and AN7583 drivers.
----------------------------------------------------------------
Abel Vesa (3):
dt-bindings: pinctrl: qcom,eliza-tlmm: Merge QUP1_SE4 lane functions
pinctrl: qcom: eliza: Merge QUP1_SE4 lanes in groups
pinctrl: qcom: eliza: Add missing sdc2 pin function mappings
Ajay Kumar Nandam (3):
pinctrl: qcom: lpass-lpi: Enable runtime PM hooks on LPASS LPI SoCs
pinctrl: qcom: lpass-lpi: Switch to PM clock framework for runtime PM
pinctrl: qcom: lpass-lpi: drop unused runtime-PM write helper
Alexander Koskovich (4):
dt-bindings: pinctrl: qcom,eliza-tlmm: Split QUP lane mirror alternates
dt-bindings: pinctrl: qcom,eliza-tlmm: Split QUP1_SE4 lanes
pinctrl: qcom: eliza: Split QUP lane mirror alternates
pinctrl: qcom: eliza: Split QUP1_SE4 lanes
Alexandre MINETTE (1):
pinctrl: qcom: Register functions before enabling pinctrl
Andre Przywara (2):
pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
Arnd Bergmann (2):
pinctrl: avoid duplicate function definitions
pinctrl: tegra238: remove unused entries
Bartosz Golaszewski (3):
dt-bindings: pinctrl: describe the Qualcomm nord-tlmm
pinctrl: qcom: add the TLMM driver for the Nord platforms
pinctrl: qcom: nord: remove duplicated pin function
Biju Das (9):
pinctrl: renesas: rzg2l: Fix incorrect PUPD register offset for
high pins during suspend/resume
dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Document reset-names
dt-bindings: pinctrl: renesas: Document RZ/G3L SoC
pinctrl: renesas: rzg2l: Make QSPI register handling conditional
pinctrl: renesas: rzg2l: Add support for selecting power source
for {WDT,AWO,ISO}
pinctrl: renesas: rzg2l: Update OEN pin validation to use exact match
pinctrl: renesas: rzg2l: Add support for RZ/G3L SoC
pinctrl: renesas: rzg2l: Simplify rzg2l_pinctrl_set_mux()
pinctrl: renesas: rzg2l: Add support for clone channel control
Billy Tsai (5):
dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
pinctrl: aspeed: Add AST2700 SoC0 support
dt-bindings: pinctrl: Add aspeed,ast2700-soc1-pinctrl
pinctrl: aspeed: Add AST2700 SoC1 support
pinctrl: aspeed: Fix GPIO mux value for ADC-capable balls
Charles Keepax (2):
pinctrl: cs42l43: Fix leaked pm reference on error path
pinctrl: cs42l43: Fix polarity on debounce
Chen-Yu Tsai (3):
pinctrl: mediatek: eint: Drop base from mtk_eint_chip_write_mask()
pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction
pinctrl: mediatek: common-v1: bypass pinctrl GPIO layer in set
GPIO direction
Christian Marangi (1):
pinctrl: Move Airoha driver to dedicated directory
Claudiu Beznea (6):
pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP
pinctrl: renesas: rzg2l: Populate struct gpio_chip::set_config
pinctrl: renesas: rzv2m: Use -ENOTSUPP instead of -EOPNOTSUPP
pinctrl: renesas: rzg2l: Keep member documentation aligned
pinctrl: renesas: rzg2l: Use tab instead of spaces
pinctrl: renesas: rzg2l: Use raw_spinlock_irqsave() on power source update
Conor Dooley (4):
pinctrl: generic: change signature of pinctrl_generic_to_map()
to pass void data
pinctrl: add new generic groups/function creation function for pinmux
pinctrl: spacemit: delete spacemit_pctrl_check_power()
pinctrl: spacemit: move over to generic pinmux dt_node_to_map
implementation
Felix Gu (2):
pinctrl: pinconf-generic: fix properties bitmap leak in parse_fw_cfg()
pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path
Fenglin Wu (2):
dt-bindings: pinctrl: qcom,pmic-gpio: Document PM8010 GPIO support
pinctrl: qcom: spmi-gpio: Add PM8010 GPIO support
Frank Li (7):
mux: add devm_mux_state_get_from_np() to get mux from child node
dt-bindings: pinctrl: Add generic pinctrl for board-level mux chips
pinctrl: extract pinctrl_generic_to_map() from
pinctrl_generic_pins_function_dt_node_to_map()
pinctrl: add optional .release_mux() callback
pinctrl: add generic board-level pinctrl driver using mux framework
mux: describe np parameter in __devm_mux_state_get()
pinctrl: Add OF dependency for PINCTRL_GENERIC_MUX
Geert Uytterhoeven (11):
pinctrl: airoha: Fix type in .pin_config_group_get() callback
pinctrl: equilibrium: Fix type in .pin_config_group_get() callback
pinctrl: ingenic: Fix type in .pin_config_group_get() callback
pinctrl: mediatek: moore: Fix type in .pin_config_group_get() callback
pinctrl: single: Fix type in .pin_config_group_get() callback
Merge tag 'renesas-r9a08g046-dt-binding-defs-tag2' into
renesas-pinctrl-for-v7.2
pinctrl: renesas: rzg2l: Fix type in .pin_config_group_get() callback
pinctrl: renesas: rzv2m: Fix type in .pin_config_group_get() callback
pinctrl: renesas: sh-pfc: Implement .pin_config_group_get() callback
pinctrl: tegra: PINCTRL_TEGRA238 should depend on ARCH_TEGRA
pinctrl: tegra: PINCTRL_TEGRA264 should depend on ARCH_TEGRA
Han Gao (1):
pinctrl: spacemit: fix NULL check in spacemit_pin_set_config
Hans Zhang (2):
pinctrl: sophgo: Use FIELD_MODIFY()
pinctrl: spacemit: Use FIELD_MODIFY()
Icenowy Zheng (1):
dt-bindings: pinctrl: mediatek: mt8188: allow gpio hogs
Jia Wang (2):
dt-bindings: pinctrl: Add UltraRISC DP1000 pinctrl controller
pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver
Joey Lu (1):
pinctrl: nuvoton: ma35d1: fix MFP register offset and pin table
Kathiravan Thirumoorthy (2):
dt-bindings: pinctrl: qcom: add IPQ9650 pinctrl
pinctrl: qcom: Introduce IPQ9650 TLMM driver
Khristine Andreea Barbulescu (1):
pinctrl: s32cc: use dev_err_probe() and improve error messages
Komal Bajaj (2):
dt-bindings: pinctrl: qcom: Document Shikra Top Level Mode Multiplexer
pinctrl: qcom: Add Shikra pinctrl driver
Krzysztof Kozlowski (12):
pinctrl: tegra: Enable easier compile testing
pinctrl: realtek: Enable compile testing
pinctrl: aspeed: Enable compile testing outside of ARCH_ASPEED
pinctrl: vt8500: Enable compile testing
dt-bindings: pinctrl: nvidia,tegra234: Add missing required block
dt-bindings: pinctrl: nvidia,tegra234: Correctly use additionalProperties
pinctrl: qcom: Unify user-visible "Qualcomm" name
pinctrl: qcom: Move MODULE_DEVICE_TABLE next to the table itself
pinctrl: bcm: Move MODULE_DEVICE_TABLE next to the table itself
pinctrl: rockchip: Move MODULE_DEVICE_TABLE next to the table itself
pinctrl: qcom: Make important drivers default (2)
pinctrl: qcom: Make important drivers default (1)
Lad Prabhakar (7):
pinctrl: renesas: rzg2l: Fix SMT register cache handling
pinctrl: renesas: rzg2l: Add SR register cache for PM suspend/resume
pinctrl: renesas: rzg2l: Handle RZ/V2H(P) IOLH configuration in PM cache
pinctrl: renesas: rzg2l: Add NOD register cache for PM suspend/resume
pinctrl: renesas: rzg2l: Handle PUPD for RZ/V2H(P) dedicated pins in PM
pinctrl: renesas: rzt2h: Remove unused variable in
rzt2h_pinctrl_register()
pinctrl: renesas: rzt2h: Skip PFC mode configuration if already set
Linus Walleij (9):
Merge branch 'ib-qcom-configs' into devel
Merge branch 'ib-mux-pinctrl' into devel
Merge tag 'renesas-pinctrl-for-v7.2-tag1' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers
into devel
pinctrl: starfive: jh7110: Use __counted_by() flexarray
pinctrl: starfive: jh7110: Avoid ifdeffery
Merge tag 'intel-pinctrl-v7.2-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel
Merge tag 'renesas-pinctrl-for-v7.2-tag2' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers
into devel
Merge tag 'renesas-pinctrl-for-v7.2-tag3' of
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers
into devel
pinctrl: Export pinctrl_get_group_selector()
Luca Leonardo Scorcia (4):
dt-bindings: pinctrl: mediatek,mt65xx: Add MT6392 pinctrl
pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset
of pins 34-39
pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset
of pins 34-39
dt-bindings: pinctrl: mediatek: mt6795: document the slew-rate property
Luca Weiss (3):
dt-bindings: pinctrl: qcom: Add SM6350 LPI pinctrl
pinctrl: qcom: lpass-lpi: Add ability to use SPARE_1 for slew control
pinctrl: qcom: Add SM6350 LPASS LPI TLMM
Maulik Shah (2):
pinctrl: qcom: Remove unused macro definitions
pinctrl: qcom: Replace open coded eoi call with irq_chip_eoi_parent()
Mayur Kumar (3):
pinctrl: bcm: fix SPDX comment style in header
pinctrl: actions: fix SPDX comment style in header
pinctrl: mediatek: fix SPDX comment style in header
Mikhail Kshevetskiy (11):
pinctrl: airoha: an7581: add missed gpio32 pin group
pinctrl: airoha: an7583: add missed gpio32 pin group
pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1
pin function
pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1
pin function
pinctrl: airoha: fix pwm pin function for an7581 and an7583
pinctrl: airoha: an7583: fix gpio21 pin group
pinctrl: airoha: an7583: add missed gpio22 pin group
pinctrl: airoha: an7583: fix phy1_led1 pin function
pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function
Navya Malempati (1):
pinctrl: qcom: Remove unused macro definitions
Oleksij Rempel (1):
pinctrl: core: Make pin group callbacks optional for pin-only drivers
Peter Griffin (1):
MAINTAINERS: add myself as co-maintainer for Samsung pinctrl drivers
Prathamesh Shete (7):
pinctrl: tegra: Export tegra_pinctrl_probe()
dt-bindings: pinctrl: Document Tegra238 pin controllers
pinctrl: tegra: Add Tegra238 pinmux driver
dt-bindings: pinctrl: Document Tegra264 pin controllers
pinctrl: tegra: Add Tegra264 pinmux driver
dt-bindings: pinctrl: tegra238: add missing AON pin groups
pinctrl: tegra238: add missing AON pin groups
Rob Herring (Arm) (1):
pinctrl: Match DT helper types
Rosen Penev (2):
pinctrl: starfive: jh7110: use struct_size
pinctrl: sophgo: allocate power_cfg with priv
Sneh Mankad (2):
pinctrl: qcom: Modify MSM_PULL_MASK to accurately represent PULL bits
pinctrl: qcom: Fix resolving register base address from device node
Stanislav Zaikin (1):
pinctrl: qcom: sm6115: Add egpio support
Stepan Ionichev (1):
pinctrl: intel: move PWM base computation past feature check
Swati Agarwal (1):
dt-bindings: pinctrl: qcom: move gpio-hog schema to tlmm-common
Thomas Weber (2):
pinctrl: qcom: Fix typo
pinctrl: realtek: Fix typo
Timur Tabi (1):
pinctrl: PINCTRL_STMFX should depend on CONFIG_OF
Uwe Kleine-König (The Capable Hub) (3):
pinctrl: Use named initializers for platform_device_id arrays
pinctrl: max77620: Unify usage of space and comma in
platform_device_id array
pinctrl: Use named initializers for arrays of i2c_device_data
Xianwei Zhao (4):
pinctrl: meson: amlogic-a4: fix gpio output glitch
dt-bindings: pinctl: amlogic,pinctrl-a4: Add compatible string for A9
pinctrl: meson: support amlogic A9 SoC
pinctrl: meson: amlogic-a4: use nolock get range
Yash Suthar (1):
pinctrl: pinconf-generic: Use kmemdup_array() over kmemdup()
Yu-Chun Lin (1):
dt-bindings: pinctrl: realtek,rtd1625: Fix input voltage property name
.../pinctrl/allwinner,sun55i-a523-pinctrl.yaml | 8 +-
.../bindings/pinctrl/amlogic,pinctrl-a4.yaml | 1 +
.../pinctrl/aspeed,ast2700-soc0-pinctrl.yaml | 188 ++
.../pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 760 +++++++
.../bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml | 1 +
.../bindings/pinctrl/mediatek,mt6795-pinctrl.yaml | 8 +
.../bindings/pinctrl/mediatek,mt8188-pinctrl.yaml | 5 +
.../pinctrl/nvidia,tegra234-pinmux-aon.yaml | 6 +-
.../bindings/pinctrl/nvidia,tegra234-pinmux.yaml | 6 +-
.../pinctrl/nvidia,tegra238-pinmux-aon.yaml | 102 +
.../pinctrl/nvidia,tegra238-pinmux-common.yaml | 73 +
.../bindings/pinctrl/nvidia,tegra238-pinmux.yaml | 219 ++
.../pinctrl/nvidia,tegra264-pinmux-aon.yaml | 80 +
.../pinctrl/nvidia,tegra264-pinmux-common.yaml | 84 +
.../pinctrl/nvidia,tegra264-pinmux-main.yaml | 167 ++
.../pinctrl/nvidia,tegra264-pinmux-uphy.yaml | 78 +
.../bindings/pinctrl/pinctrl-multiplexer.yaml | 57 +
.../devicetree/bindings/pinctrl/pinctrl.yaml | 2 +-
.../bindings/pinctrl/qcom,eliza-tlmm.yaml | 26 +-
.../bindings/pinctrl/qcom,ipq4019-pinctrl.yaml | 5 -
.../bindings/pinctrl/qcom,ipq9650-tlmm.yaml | 118 ++
.../bindings/pinctrl/qcom,nord-tlmm.yaml | 141 ++
.../bindings/pinctrl/qcom,pmic-gpio.yaml | 3 +
.../bindings/pinctrl/qcom,sdm845-pinctrl.yaml | 5 -
.../bindings/pinctrl/qcom,shikra-tlmm.yaml | 123 ++
.../pinctrl/qcom,sm6350-lpass-lpi-pinctrl.yaml | 124 ++
.../bindings/pinctrl/qcom,tlmm-common.yaml | 6 +
.../bindings/pinctrl/realtek,rtd1625-pinctrl.yaml | 2 +-
.../bindings/pinctrl/renesas,rzg2l-pinctrl.yaml | 35 +
.../bindings/pinctrl/ultrarisc,dp1000-pinctrl.yaml | 130 ++
MAINTAINERS | 10 +-
arch/arm/configs/multi_v7_defconfig | 8 -
arch/arm/configs/qcom_defconfig | 15 -
arch/arm64/configs/defconfig | 46 -
drivers/mux/core.c | 43 +-
drivers/pinctrl/Kconfig | 13 +
drivers/pinctrl/Makefile | 11 +-
drivers/pinctrl/actions/pinctrl-owl.h | 2 +-
drivers/pinctrl/airoha/Kconfig | 20 +
drivers/pinctrl/airoha/Makefile | 3 +
.../pinctrl/{mediatek => airoha}/pinctrl-airoha.c | 124 +-
drivers/pinctrl/aspeed/Kconfig | 23 +
drivers/pinctrl/aspeed/Makefile | 2 +
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc0.c | 749 +++++++
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c | 1756 ++++++++++++++++
drivers/pinctrl/bcm/pinctrl-bcm4908.c | 2 +-
drivers/pinctrl/bcm/pinctrl-bcm63xx.h | 2 +-
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 2 +-
drivers/pinctrl/bcm/pinctrl-ns.c | 2 +-
drivers/pinctrl/cirrus/pinctrl-cs42l43.c | 10 +-
drivers/pinctrl/core.c | 41 +-
drivers/pinctrl/intel/pinctrl-broxton.c | 4 +-
drivers/pinctrl/intel/pinctrl-denverton.c | 2 +-
drivers/pinctrl/intel/pinctrl-intel.c | 3 +-
drivers/pinctrl/mediatek/Kconfig | 17 +-
drivers/pinctrl/mediatek/Makefile | 1 -
drivers/pinctrl/mediatek/mtk-eint.c | 6 +-
drivers/pinctrl/mediatek/pinctrl-moore.c | 3 +-
drivers/pinctrl/mediatek/pinctrl-mt8167.c | 2 +-
drivers/pinctrl/mediatek/pinctrl-mt8516.c | 2 +-
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 13 +-
drivers/pinctrl/mediatek/pinctrl-mtk-mt8365.h | 2 +-
drivers/pinctrl/mediatek/pinctrl-paris.c | 8 +-
drivers/pinctrl/meson/pinctrl-amlogic-a4.c | 86 +-
drivers/pinctrl/nuvoton/pinctrl-ma35.c | 3 +-
drivers/pinctrl/nuvoton/pinctrl-ma35d1.c | 470 +++--
drivers/pinctrl/nxp/pinctrl-s32cc.c | 64 +-
drivers/pinctrl/pinconf-generic.c | 7 +-
drivers/pinctrl/pinconf.c | 9 +-
drivers/pinctrl/pinconf.h | 32 +-
drivers/pinctrl/pinctrl-aw9523.c | 2 +-
drivers/pinctrl/pinctrl-cy8c95x0.c | 6 +-
drivers/pinctrl/pinctrl-equilibrium.c | 3 +-
drivers/pinctrl/pinctrl-generic-mux.c | 184 ++
drivers/pinctrl/pinctrl-generic.c | 211 +-
drivers/pinctrl/pinctrl-ingenic.c | 3 +-
drivers/pinctrl/pinctrl-max77620.c | 6 +-
drivers/pinctrl/pinctrl-mcp23s08_i2c.c | 6 +-
drivers/pinctrl/pinctrl-mcp23s08_spi.c | 6 +-
drivers/pinctrl/pinctrl-rockchip.c | 2 +-
drivers/pinctrl/pinctrl-single.c | 3 +-
drivers/pinctrl/pinctrl-sx150x.c | 20 +-
drivers/pinctrl/pinctrl-tps6594.c | 4 +-
drivers/pinctrl/pinmux.c | 5 +
drivers/pinctrl/qcom/Kconfig | 35 +-
drivers/pinctrl/qcom/Kconfig.msm | 173 +-
drivers/pinctrl/qcom/Makefile | 4 +
drivers/pinctrl/qcom/pinctrl-apq8064.c | 2 +-
drivers/pinctrl/qcom/pinctrl-apq8084.c | 2 +-
drivers/pinctrl/qcom/pinctrl-eliza.c | 188 +-
drivers/pinctrl/qcom/pinctrl-glymur.c | 2 +-
drivers/pinctrl/qcom/pinctrl-hawi.c | 2 +-
drivers/pinctrl/qcom/pinctrl-ipq4019.c | 2 +-
drivers/pinctrl/qcom/pinctrl-ipq6018.c | 2 +-
drivers/pinctrl/qcom/pinctrl-ipq8064.c | 2 +-
drivers/pinctrl/qcom/pinctrl-ipq8074.c | 2 +-
drivers/pinctrl/qcom/pinctrl-ipq9650.c | 762 +++++++
drivers/pinctrl/qcom/pinctrl-kaanapali.c | 2 +-
drivers/pinctrl/qcom/pinctrl-lpass-lpi.c | 136 +-
drivers/pinctrl/qcom/pinctrl-lpass-lpi.h | 20 +
drivers/pinctrl/qcom/pinctrl-mdm9607.c | 2 +-
drivers/pinctrl/qcom/pinctrl-mdm9615.c | 2 +-
drivers/pinctrl/qcom/pinctrl-milos-lpass-lpi.c | 7 +
drivers/pinctrl/qcom/pinctrl-milos.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm.c | 21 +-
drivers/pinctrl/qcom/pinctrl-msm8226.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8660.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8916.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8953.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8960.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8976.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8994.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8996.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8998.c | 2 +-
drivers/pinctrl/qcom/pinctrl-msm8x74.c | 2 +-
drivers/pinctrl/qcom/pinctrl-nord.c | 1770 ++++++++++++++++
drivers/pinctrl/qcom/pinctrl-qcm2290.c | 25 +-
drivers/pinctrl/qcom/pinctrl-qcs404.c | 2 +-
drivers/pinctrl/qcom/pinctrl-qcs615.c | 2 +-
drivers/pinctrl/qcom/pinctrl-qcs8300.c | 6 -
drivers/pinctrl/qcom/pinctrl-qdu1000.c | 30 -
drivers/pinctrl/qcom/pinctrl-sa8775p.c | 6 -
drivers/pinctrl/qcom/pinctrl-sc7180.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sc7280-lpass-lpi.c | 19 +-
drivers/pinctrl/qcom/pinctrl-sc7280.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sc8280xp-lpass-lpi.c | 15 +-
drivers/pinctrl/qcom/pinctrl-sdm660-lpass-lpi.c | 7 +
drivers/pinctrl/qcom/pinctrl-sdm660.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 7 +
drivers/pinctrl/qcom/pinctrl-sdm845.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sdx55.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sdx65.c | 2 +-
drivers/pinctrl/qcom/pinctrl-shikra.c | 1253 +++++++++++
drivers/pinctrl/qcom/pinctrl-sm4250-lpass-lpi.c | 7 +
drivers/pinctrl/qcom/pinctrl-sm4450.c | 7 -
drivers/pinctrl/qcom/pinctrl-sm6115-lpass-lpi.c | 7 +
drivers/pinctrl/qcom/pinctrl-sm6115.c | 42 +-
drivers/pinctrl/qcom/pinctrl-sm6125.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm6350-lpass-lpi.c | 156 ++
drivers/pinctrl/qcom/pinctrl-sm6350.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm6375.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8150.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8250-lpass-lpi.c | 15 +-
drivers/pinctrl/qcom/pinctrl-sm8250.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8350.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8450-lpass-lpi.c | 15 +-
drivers/pinctrl/qcom/pinctrl-sm8450.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8550-lpass-lpi.c | 15 +-
drivers/pinctrl/qcom/pinctrl-sm8550.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8650-lpass-lpi.c | 15 +-
drivers/pinctrl/qcom/pinctrl-sm8650.c | 2 +-
drivers/pinctrl/qcom/pinctrl-sm8750.c | 2 +-
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 10 +-
drivers/pinctrl/qcom/pinctrl-x1e80100.c | 2 +-
drivers/pinctrl/qcom/tlmm-test.c | 21 +-
drivers/pinctrl/realtek/Kconfig | 12 +-
drivers/pinctrl/realtek/pinctrl-rtd.c | 12 +-
drivers/pinctrl/renesas/core.c | 24 +-
drivers/pinctrl/renesas/pinctrl-rzg2l.c | 611 +++++-
drivers/pinctrl/renesas/pinctrl-rzt2h.c | 13 +-
drivers/pinctrl/renesas/pinctrl-rzv2m.c | 7 +-
drivers/pinctrl/renesas/pinctrl.c | 25 +
drivers/pinctrl/sophgo/pinctrl-cv18xx.c | 32 +-
drivers/pinctrl/spacemit/Kconfig | 4 +-
drivers/pinctrl/spacemit/pinctrl-k1.c | 182 +-
drivers/pinctrl/starfive/pinctrl-starfive-jh7110.c | 13 +-
drivers/pinctrl/starfive/pinctrl-starfive-jh7110.h | 3 +-
drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 2 +-
drivers/pinctrl/tegra/Kconfig | 44 +-
drivers/pinctrl/tegra/Makefile | 2 +
drivers/pinctrl/tegra/pinctrl-tegra.c | 2 +
drivers/pinctrl/tegra/pinctrl-tegra238.c | 2080 ++++++++++++++++++
drivers/pinctrl/tegra/pinctrl-tegra264.c | 2216 ++++++++++++++++++++
drivers/pinctrl/ultrarisc/Kconfig | 20 +
drivers/pinctrl/ultrarisc/Makefile | 4 +
drivers/pinctrl/ultrarisc/pinctrl-dp1000.c | 168 ++
drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.c | 517 +++++
drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.h | 63 +
drivers/pinctrl/vt8500/Kconfig | 13 +-
.../dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h | 39 +
.../pinctrl/renesas,r9a08g046-pinctrl.h | 38 +
include/linux/mux/consumer.h | 8 +-
include/linux/pinctrl/pinmux.h | 5 +
186 files changed, 16504 insertions(+), 1176 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc0-pinctrl.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra238-pinmux-aon.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra238-pinmux-common.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra238-pinmux.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra264-pinmux-aon.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra264-pinmux-common.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra264-pinmux-main.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/nvidia,tegra264-pinmux-uphy.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/pinctrl-multiplexer.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,ipq9650-tlmm.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,nord-tlmm.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,shikra-tlmm.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,sm6350-lpass-lpi-pinctrl.yaml
create mode 100644
Documentation/devicetree/bindings/pinctrl/ultrarisc,dp1000-pinctrl.yaml
create mode 100644 drivers/pinctrl/airoha/Kconfig
create mode 100644 drivers/pinctrl/airoha/Makefile
rename drivers/pinctrl/{mediatek => airoha}/pinctrl-airoha.c (95%)
create mode 100644 drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc0.c
create mode 100644 drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
create mode 100644 drivers/pinctrl/pinctrl-generic-mux.c
create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq9650.c
create mode 100644 drivers/pinctrl/qcom/pinctrl-nord.c
create mode 100644 drivers/pinctrl/qcom/pinctrl-shikra.c
create mode 100644 drivers/pinctrl/qcom/pinctrl-sm6350-lpass-lpi.c
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra238.c
create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra264.c
create mode 100644 drivers/pinctrl/ultrarisc/Kconfig
create mode 100644 drivers/pinctrl/ultrarisc/Makefile
create mode 100644 drivers/pinctrl/ultrarisc/pinctrl-dp1000.c
create mode 100644 drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.c
create mode 100644 drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.h
create mode 100644 include/dt-bindings/pinctrl/mediatek,mt6392-pinfunc.h
create mode 100644 include/dt-bindings/pinctrl/renesas,r9a08g046-pinctrl.h
^ permalink raw reply
* Re: [PATCH v9 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
From: Hardik Prakash @ 2026-06-18 10:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-i2c, linux-gpio, wsa, mario.limonciello, brgl,
basavaraj.natikar, linusw, nathan, chaitanya.kumar.borah
In-Reply-To: <ajOWV3apVXOAHcYT@ashevche-desk.local>
On Thu, Jun 18, 2026 at 12:25, Andy Shevchenko wrote:
> So the question is, do we expect the resource_source not to be set at
> this point? In other words is there any valid AML that interpreter
> decodes to the empty resource_source? If so, can we ever have the
> following condition to be true?
>
> string_length != 0 && string_ptr == NULL
I checked the ACPICA parser in drivers/acpi/acpica/rsutils.c. The
acpi_rs_get_resource_source() helper always assigns string_ptr before
string_length when the resource source is present. When it is absent,
both are cleared together (string_length = 0, string_ptr = NULL). So
string_length != 0 && string_ptr == NULL cannot be produced by normal
AML parsing.
Therefore checking string_length alone is sufficient:
if (!agpio->resource_source.string_length)
return 1;
I'll simplify to this in v10.
> You haven't replied to the rest, I assume you agree with all the
> suggestions?
Yes, I agree with all the remaining suggestions and will address them
in v10:
- acpi_dev_get_resources() on single line, free only on success path
- Reversed xmas tree ordering for variable declarations
- Remove useless int ret = 0 assignment
- acpi_dev_for_each_child() on single line
- Use guard(device)(gpio_dev) pattern to avoid uninitialized variable
warning and deduplicate the !gpio_dev check
Thanks,
Hardik
On Thu, 18 Jun 2026 at 12:25, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Thu, Jun 18, 2026 at 12:52:46AM +0530, Hardik Prakash wrote:
> > On Wed, Jun 17, 2026 at 14:57, Andy Shevchenko wrote:
>
> > > > + if (!agpio->resource_source.string_length ||
> > > > + !agpio->resource_source.string_ptr)
> > > > + return 1;
> > >
> > > I'm wondering if we simply can move to strncmp() instead of this check
> > >
> > > > + list_for_each_entry(ref, gpio_controllers, node) {
> > > > + if (!strcmp(ref->path, agpio->resource_source.string_ptr))
> > >
> > > if (!strncmp(ref->path, agpio->resource_source.string_ptr))
> >
> > Could you clarify? strncmp() with n=string_length would protect the
> > dedup check against a NULL or unterminated string_ptr, but we still
> > need string_ptr to be non-NULL before passing it to kstrdup(). Should
> > we keep a NULL/zero-length guard before kstrdup() and only replace the
> > strcmp() in the dedup loop with strncmp()?
>
> Ah, okay, you are talking about the first iteration when the list is empty and
> we have to add it to the list.
>
> So the question is, do we expect the resource_source not to be set at this point?
> In other words is there any valid AML that interpreter decodes to the empty
> resource_source? If so, can we ever have the following condition to be true?
>
> string_length != 0 && string_ptr == NULL
>
> P.S. Do not top-post! Reply under the piece in question. Also remove
> the context you are not replying to.
>
> > On Wed, 17 Jun 2026 at 14:57, Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > > On Wed, Jun 17, 2026 at 12:29:22PM +0530, Hardik Prakash wrote:
>
> ...
>
> > > > +static int check_gpioint_resource(struct acpi_resource *ares, void *data)
> > > > +{
> > > > + struct list_head *gpio_controllers = data;
> > > > + struct acpi_resource_gpio *agpio;
> > > > + struct gpio_controller_ref *ref;
> > > > +
> > > > + if (!acpi_gpio_get_irq_resource(ares, &agpio))
> > > > + return 1;
> > >
> > > > + if (!agpio->resource_source.string_length ||
> > > > + !agpio->resource_source.string_ptr)
> > > > + return 1;
> > >
> > > I'm wondering if we simply can move to strncmp() instead of this check
> > >
> > > > + /* Skip if we've already tracked this GPIO controller */
> > > > + list_for_each_entry(ref, gpio_controllers, node) {
> > > > + if (!strcmp(ref->path, agpio->resource_source.string_ptr))
> > >
> > > if (!strncmp(ref->path, agpio->resource_source.string_ptr))
> > >
> > >
> > > > + return 1;
> > > > + }
> > > > +
> > > > + ref = kzalloc(sizeof(*ref), GFP_KERNEL);
> > > > + if (!ref)
> > > > + return -ENOMEM;
> > > > +
> > > > + ref->path = kstrdup(agpio->resource_source.string_ptr, GFP_KERNEL);
> > > > + if (!ref->path) {
> > > > + kfree(ref);
> > > > + return -ENOMEM;
> > > > + }
> > > > +
> > > > + list_add_tail(&ref->node, gpio_controllers);
> > > > + return 1;
> > > > +}
>
> You haven't replied to the rest, I assume you agree with all the suggestions?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH] pinctrl: Match DT helper types
From: Florian Fainelli @ 2026-06-18 10:24 UTC (permalink / raw)
To: Rob Herring (Arm), Linus Walleij, Ray Jui, Scott Branden,
Broadcom internal kernel review list
Cc: linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260612214939.1883911-1-robh@kernel.org>
On 6/12/2026 2:49 PM, 'Rob Herring (Arm)' via
BCM-KERNEL-FEEDBACK-LIST,PDL wrote:
> The affected pinctrl drivers either check for the presence of a standard
> property or read a property documented with an 8-bit cell encoding.
> Using boolean or u32 helpers for those cases disagrees with the binding.
>
> Use a presence helper for "gpio-ranges" and read
> "microchip,spi-present-mask" with the u8 helper documented by the
> binding.
>
> Assisted-by: Codex:gpt-5-5
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
From: Herve Codina @ 2026-06-18 9:54 UTC (permalink / raw)
To: Viresh Kumar
Cc: Runyu Xiao, Viresh Kumar, Linus Walleij,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
linux-arm-kernel, soc, linux-gpio, linux-rt-devel, linux-kernel,
jianhao.xu
In-Reply-To: <sj3oxg5ymbe2ac2geznsidsxz23rkqzqc4ir3pkjc7bsrzaorw@cw3waaj6xxkx>
Hi,
On Thu, 18 Jun 2026 13:10:31 +0530
Viresh Kumar <viresh.kumar@linaro.org> wrote:
> + Herve (the last guy to work on this driver).
>
> On 18-06-26, 10:34, Runyu Xiao wrote:
> > Hi,
> >
> > While auditing GPIO/pinctrl irqchip callbacks, our static analysis tool
> > flagged the SPEAr PLGPIO irq_enable path, and we manually reviewed it
> > against the current tree.
> >
> > The path is:
> >
> > irq_startup()
> > -> plgpio_irq_enable()
> > -> gpiochip_enable_irq()
> > -> spin_lock_irqsave(&plgpio->lock)
> > -> plgpio_reg_reset()
> > -> regmap_update_bits()
> >
> > On PREEMPT_RT, plgpio->lock is a regular spinlock_t and can become a
> > sleeping lock. Since irq_enable/irq_disable can be called from IRQ
> > management paths while the IRQ descriptor raw lock is held, taking that
> > regular spinlock there looks unsafe.
> >
> > A minimal Lockdep reproducer preserving this irq_chip::irq_enable carrier
> > reports:
> >
> > BUG: sleeping function called from invalid context
> > irqs_disabled(): 1
> > plgpio_rt_spin_lock_irqsave
> > plgpio_irq_enable
> > request_threaded_irq_probe_path
> >
> > My first thought was to convert the PLGPIO register lock to
> > raw_spinlock_t. However, that does not seem sufficient because the IE/EIT
> > updates go through regmap_update_bits()/regmap_read()/regmap_write(). For
> > the syscon/MMIO regmap used here, regmap may still take its own regular
> > fast-IO lock unless the regmap was created with use_raw_spinlock. So a
> > raw_spinlock_t conversion in the PLGPIO driver alone may just move the
> > PREEMPT_RT problem one level down into regmap.
> >
> > The repair I am considering is to keep the gpiolib resource updates in
> > the fast irq_enable/irq_disable callbacks, but defer the actual PLGPIO
> > IE/EIT register writes to irq_bus_sync_unlock(), after the IRQ core has
> > dropped desc->lock. The driver would keep per-line shadow state for:
> >
> > - IRQ disabled/enabled state
> > - pending IE update
> > - edge direction state
> > - pending EIT update
> >
> > and then synchronize those shadow updates from irq_bus_sync_unlock()
> > under a mutex.
> >
> > In other words, the fast callbacks would only update local shadow state
> > and call gpiochip_enable_irq()/gpiochip_disable_irq(), while the sleepable
> > regmap writes would be batched into the irq bus sync phase.
> >
> > Does that sound like an acceptable direction for SPEAr PLGPIO, or would
> > you prefer a different fix, such as changing the underlying syscon regmap
> > locking model or handling only the IE register path?
> >
> > The draft patch I have locally is roughly:
> >
> > pinctrl: spear: defer PLGPIO IRQ updates to bus sync
> >
> > and it changes only drivers/pinctrl/spear/pinctrl-plgpio.c.
>
> I haven't worked on this for a very long time now (15 yrs). There are some
> people who use this hardware, and so it is not removed until now.
>
> Also I am not sure if RT kernel is a valid use case here for this SoC family.
>
I know some users and they don't use RT kernel.
But well, isn't the pattern present in some other gpio controller drivers ?
How it is done in others ?
What is specific in this controller compare to others ?
We take and release spinlock in gpio chip .irq_enable(). I think we can
find other drivers doing that and probably drivers using a regmap as well.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v2 2/2] pinctrl: qcom: Add the tlmm driver for Maili platform
From: Konrad Dybcio @ 2026-06-18 9:02 UTC (permalink / raw)
To: Jingyi Wang, Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260614-maili-pinctrl-v2-2-0db5bfc23d64@oss.qualcomm.com>
On 6/15/26 8:55 AM, Jingyi Wang wrote:
> Add support for Maili TLMM configuration and control via the pinctrl
> framework.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
[...]
> +/* Every pin is maintained as a single group, and missing or non-existing pin
> + * would be maintained as dummy group to synchronize pin group index with
> + * pin descriptor registered with pinctrl core.
> + * Clients would not be able to request these dummy pin groups.
> + */
Let's drop this comment
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v3] pinctrl: qcom: Unconditionally mark gpio as wakeup enable
From: Konrad Dybcio @ 2026-06-18 8:49 UTC (permalink / raw)
To: Sneh Mankad, Bjorn Andersson, Linus Walleij, Neil Armstrong,
Krzysztof Kozlowski
Cc: linux-arm-msm, linux-gpio, linux-kernel, stable, Maulik Shah
In-Reply-To: <20260616-enable_wakeup_capable_gpios-v3-1-fb59647d89cb@oss.qualcomm.com>
On 6/16/26 1:54 PM, Sneh Mankad wrote:
> GPIO interrupts that are wakeup capable need to be forwarded to wakeup
> capable parent irqchip. This is done via writing to it's wakeup_enable bit.
>
> Currently the bit is set only for PDC irqchip by checking skip_wake_irqs.
> skip_wake_irqs is set to differentiate between parent irqchips MPM and
> PDC. It is set when the parent irqchip is PDC to inform pinctrl about
> skipping the IRQ setting up at TLMM.
>
> However, the functionality to forward GPIO interrupts during SoC low
> power mode is needed regardless of which parent irqchip it is.
> Without the functionality it is impossible for MPM irqchip to detect the
> GPIO interrupt during SoC low power mode since for MPM irqchip the
> skip_wake_irqs is always false.
This is a much better commit message, thank you!
One question remains - should we set skip_wake_irqs for MPM too?
My understanding is that no, since the MPM HW is simpler and doesn't
have a register for acking IRQs, so we need to do it from the recipient
(TLMM). Is that right?
Konrad
^ permalink raw reply
* Re: [PATCH v3 8/8] arm64: dts: qcom: x1e80100: Add deepest idle state
From: Konrad Dybcio @ 2026-06-18 8:25 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-8-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> Add deepest idle state as GPIO IRQs can work as wakeup capable interrupts
> in deepest idle state.
>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> index 4ba751a65142..47e425003028 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -302,6 +302,14 @@ cluster_cl5: cluster-sleep-1 {
> exit-latency-us = <4000>;
> min-residency-us = <7000>;
> };
> +
> + domain_ss3: domain-sleep-0 {
> + compatible = "domain-idle-state";
> + arm,psci-suspend-param = <0x0200c354>;
> + entry-latency-us = <2800>;
> + exit-latency-us = <4400>;
The DSDT has "wake_latency" (presumably the same as exit latency) set
to 5000 us, should we follow?
FWIW, the 2800/4400 numbers here are the exact same as for sm8650..
which doesn't sound very reassuring
> + min-residency-us = <9000>;
This number matches the DSDT
Should the entry latency then be 9000 - 5000 = 4000?
On a separate note, the DSDT also defines:
SS1 (0x02000154, total=7500, exit=500)
SS2 (0x02000254, total=8000, exit=3000)
These are obviously shallower states, but perhaps they could still
be useful?
Konrad
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Konrad Dybcio @ 2026-06-18 8:19 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-5-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> All PDC irqchip supports pass through mode in which both Direct SPIs and
> GPIO IRQs (as SPIs) are sent to GIC without latching at PDC.
>
> Newer PDCs (v3.0 onwards) also support additional secondary controller mode
> where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs
> still works same as pass through mode without latching at PDC even in
> secondary controller mode.
>
> All the SoCs so far default uses pass through mode with the exception of
> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
> boards whereas it may be set to pass through mode for IoT-EVK boards.
> The mode configuration is done in firmware and initially shipped windows
> firmware did not have SCM interface to read or modify the PDC mode.
> Later only write access is opened up for non secure world.
>
> Using the write access available add changes to modify the PDC mode to
> pass through mode via SCM write. When the write fails (on older firmware)
> assume to work in secondary mode.
>
> In secondary mode set the separate irqchip for the GPIOs to perform
> additional operations only for the GPIO irqs.
>
> Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
[...]
> +static void pdc_clear_gpio_cfg(int pin_out)
> +{
> + unsigned long gpio_sts;
> +
> + if (pdc->version < PDC_VERSION_3_0)
> + return;
> +
> + gpio_sts = pdc_reg_read(pdc->regs->irq_cfg_reg, pin_out);
> + __clear_bit(pdc->cfg_fields->gpio_irq_sts, &gpio_sts);
> + pdc_reg_write(pdc->regs->irq_cfg_reg, pin_out, gpio_sts);
> +}
> +
> +static void pdc_unmask_gpio_cfg(int pin_out, bool unmask)
> +{
> + unsigned long gpio_mask;
> +
> + if (pdc->version < PDC_VERSION_3_0)
> + return;
These version checks should be unnecessary now, given the function pointer
is only assigned for hamoa
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] gpio: sch: use raw_spinlock_t in the irq startup path
From: Sebastian Andrzej Siewior @ 2026-06-18 8:18 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Runyu Xiao, Linus Walleij, Bartosz Golaszewski, Orson Zhai,
Baolin Wang, Chunyan Zhang, Andy Shevchenko, Clark Williams,
Steven Rostedt, Jan Kiszka, linux-gpio, linux-rt-devel,
linux-kernel, jianhao.xu, stable
In-Reply-To: <ajOTLrrUCBxsy5jf@ashevche-desk.local>
On 2026-06-18 09:41:50 [+0300], Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 09:40:31AM +0300, Andy Shevchenko wrote:
> > On Thu, Jun 18, 2026 at 08:28:39AM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2026-06-17 23:40:34 [+0800], Runyu Xiao wrote:
> > > > sch_irq_unmask() enables the GPIO IRQ and then updates the controller
> > > > state through sch_irq_mask_unmask(), which takes sch->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.
> …
> > > > Fixes: 7a81638485c1 ("gpio: sch: Add edge event support")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> > >
> > > Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> >
> > There is already a v2.
>
> Or not... I might have been confused with other patch that got two versions
> in a row.
I am catching up so I wouldn't be surprised ;) And it is entirely
possible that sashiko came up with the pre-existing condition worth
fixing ;)
Sebastian
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Konrad Dybcio @ 2026-06-18 8:18 UTC (permalink / raw)
To: Maulik Shah, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <20260616-hamoa_pdc_v3-v3-5-4d8e1504ea75@oss.qualcomm.com>
On 6/16/26 11:25 AM, Maulik Shah wrote:
> All PDC irqchip supports pass through mode in which both Direct SPIs and
> GPIO IRQs (as SPIs) are sent to GIC without latching at PDC.
>
> Newer PDCs (v3.0 onwards) also support additional secondary controller mode
> where PDC latches GPIO IRQs and sends to GIC as level type IRQ. Direct SPIs
> still works same as pass through mode without latching at PDC even in
> secondary controller mode.
>
> All the SoCs so far default uses pass through mode with the exception of
> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
> boards whereas it may be set to pass through mode for IoT-EVK boards.
> The mode configuration is done in firmware and initially shipped windows
> firmware did not have SCM interface to read or modify the PDC mode.
> Later only write access is opened up for non secure world.
>
> Using the write access available add changes to modify the PDC mode to
> pass through mode via SCM write. When the write fails (on older firmware)
> assume to work in secondary mode.
>
> In secondary mode set the separate irqchip for the GPIOs to perform
> additional operations only for the GPIO irqs.
>
> Co-developed-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> Signed-off-by: Sneh Mankad <sneh.mankad@oss.qualcomm.com>
> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
> ---
[...]
> +static int qcom_pdc_gic_secondary_set_type(struct irq_data *d, unsigned int type)
> +{
> + enum pdc_irq_config_bits pdc_type;
> + enum pdc_irq_config_bits old_pdc_type;
> + int ret;
> +
> + switch (type) {
> + case IRQ_TYPE_EDGE_RISING:
> + pdc_type = PDC_EDGE_RISING;
> + break;
> + case IRQ_TYPE_EDGE_FALLING:
> + pdc_type = PDC_EDGE_FALLING;
> + break;
> + case IRQ_TYPE_EDGE_BOTH:
> + pdc_type = PDC_EDGE_DUAL;
> + break;
> + case IRQ_TYPE_LEVEL_HIGH:
> + pdc_type = PDC_LEVEL_HIGH;
> + break;
> + case IRQ_TYPE_LEVEL_LOW:
> + pdc_type = PDC_LEVEL_LOW;
> + break;
> + default:
> + WARN_ON(1);
> + return -EINVAL;
> + }
> +
> + old_pdc_type = pdc_reg_read(pdc->regs->irq_cfg_reg, d->hwirq);
> + pdc_type |= (old_pdc_type & ~pdc->cfg_fields->irq_type);
> + pdc_reg_write(pdc->regs->irq_cfg_reg, d->hwirq, pdc_type);
> +
> + type = IRQ_TYPE_LEVEL_HIGH;
Please carry your comment from the previous revision:
/*
* PDC forwards GPIOs as level high to GIC in secondary
* mode. Update the type and clear any previously latched
* phantom interrupt at PDC.
*/
> + pdc->clear_gpio(d->hwirq);
> +
> + ret = irq_chip_set_type_parent(d, type);
> + if (ret)
> + return ret;
> +
> + /*
> + * When we change types the PDC can give a phantom interrupt.
> + * Clear it. Specifically the phantom shows up when reconfiguring
> + * polarity of interrupt without changing the state of the signal
> + * but let's be consistent and clear it always.
> + *
> + * Doing this works because we have IRQCHIP_SET_TYPE_MASKED so the
> + * interrupt will be cleared before the rest of the system sees it.
> + */
> + if (old_pdc_type != pdc_type)
> + irq_chip_set_parent_state(d, IRQCHIP_STATE_PENDING, false);
This bit and the switch statement above are common between the two paths..
I'm debating whether we should factor them out as static inline void, but
neither solution is perfect.. so, up to you
[...]
> @@ -385,20 +547,37 @@ static int qcom_pdc_alloc(struct irq_domain *domain, unsigned int virq,
> if (hwirq == GPIO_NO_WAKE_IRQ)
> return irq_domain_disconnect_hierarchy(domain, virq);
>
> - ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> - &qcom_pdc_gic_chip, NULL);
> - if (ret)
> - return ret;
> + /*
> + * PDC secondary chip is only set for the GPIO interrupts as SPIs.
> + * Direct SPI interrupts are still in pass through mode (no latching
> + * at PDC).
> + */
> + if (pdc->mode == PDC_PASS_THROUGH_MODE || !pdc_pin_is_gpio(hwirq)) {
> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> + &qcom_pdc_gic_chip,
> + NULL);
> + if (ret)
> + return ret;
>
> - region = get_pin_region(hwirq);
> - if (!region)
> - return irq_domain_disconnect_hierarchy(domain->parent, virq);
> + if (type & IRQ_TYPE_EDGE_BOTH)
> + type = IRQ_TYPE_EDGE_RISING;
>
> - if (type & IRQ_TYPE_EDGE_BOTH)
> - type = IRQ_TYPE_EDGE_RISING;
> + if (type & IRQ_TYPE_LEVEL_MASK)
> + type = IRQ_TYPE_LEVEL_HIGH;
> + } else {
> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> + &qcom_pdc_gic_secondary_chip,
> + NULL);
> + if (ret)
> + return ret;
>
> - if (type & IRQ_TYPE_LEVEL_MASK)
> + /* Secondary mode converts all interrupts to LEVEL HIGH type */
> type = IRQ_TYPE_LEVEL_HIGH;
> + }
nit: (pdc->mode == PDC_SECONDARY_MODE && pdc_pin_is_gpio(hwirq))
could be the primary case to better communicate intent
Konrad
^ 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