All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Guenter Roeck <linux@roeck-us.net>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Lee Jones <lee@kernel.org>,
	Peter Rosin <peda@axentia.se>, Linus Walleij <linusw@kernel.org>,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-gpio@vger.kernel.org, David Jander <david@protonic.nl>,
	biju.das.jz@bp.renesas.com, tomm.merciai@gmail.com
Subject: Re: [PATCH v3 4/7] gpio: gpiolib: fix allocation order in hierarchical IRQ domains
Date: Fri, 13 Mar 2026 11:42:34 +0100	[thread overview]
Message-ID: <abPqGvy5FqJ0a0ug@tom-desktop> (raw)
In-Reply-To: <20260309134920.1918294-5-o.rempel@pengutronix.de>

Hi Oleksij,
Thanks for your patch.

I'm working on DSI support for RZ/G3E

from this morning rebasing on top of next-20260312 I'm seeing
the following:


[   19.230966] [drm] Initialized rzg2l-du 1.0.0 for 16490000.display on minor 2
[   19.240377] rzg2l-du 16490000.display: [drm] Device 16490000.display probed
[   19.250504] irq 165, desc: 000000004f0a321f, depth: 0, count: 0, unhandled: 0
[   19.257630] ->handle_irq():  00000000a74f5df5, handle_bad_irq+0x0/0x25c
[   19.264223] ->irq_data.chip(): 0000000057261646, rzg2l_gpio_irqchip+0x0/0x118
[   19.271328] ->action(): 0000000027be85a3
[   19.275227] ->action->handler(): 00000000e5c70c61, irq_default_primary_handler+0x0/0x8
[   20.645894] ov5645 0-003c: ov5645_write_reg: write reg error -110: reg=300e, val=58
[   40.257787] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   40.263915] rcu:     (detected by 2, t=5253 jiffies, g=3325, q=241 ncpus=4)
[   40.270632] rcu: All QSes seen, last rcu_preempt kthread activity 5255 (4294902363-4294897108), jiffies_till_next_fqs=1, root ->qsmask 0x0
[   40.283054] rcu: rcu_preempt kthread timer wakeup didn't happen for 5257 jiffies! g3325 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[   40.294351] rcu:     Possible timer handling issue on cpu=0 timer-softirq=1342
[   40.301309] rcu: rcu_preempt kthread starved for 5262 jiffies! g3325 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[   40.311657] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[   40.320771] rcu: RCU grace-period kthread stack dump:
[   40.325821] task:rcu_preempt     state:R stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000010
[   40.336886] Call trace:
[   40.339345]  __switch_to+0xec/0x1a8 (T)
[   40.343236]  __schedule+0x360/0xe18
[   40.346763]  schedule+0x34/0x110
[   40.350029]  schedule_timeout+0x84/0x100
[   40.353997]  rcu_gp_fqs_loop+0x114/0x420
[   40.357963]  rcu_gp_kthread+0x100/0x114
[   40.361843]  kthread+0x118/0x124
[   40.365122]  ret_from_fork+0x10/0x20
[   40.368740] rcu: Stack dump where RCU GP kthread last ran:
[   40.374223] Sending NMI from CPU 2 to CPUs 0:
[  113.405786] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  113.411908] rcu:     (detected by 3, t=23540 jiffies, g=3325, q=259 ncpus=4)
[  113.418711] rcu: All QSes seen, last rcu_preempt kthread activity 23542 (4294920650-4294897108), jiffies_till_next_fqs=1, root ->qsmask 0x0
[  113.431220] rcu: rcu_preempt kthread timer wakeup didn't happen for 23544 jiffies! g3325 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[  113.442606] rcu:     Possible timer handling issue on cpu=0 timer-softirq=1342
[  113.449564] rcu: rcu_preempt kthread starved for 23549 jiffies! g3325 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[  113.459998] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[  113.469112] rcu: RCU grace-period kthread stack dump:
[  113.474163] task:rcu_preempt     state:R stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000010
[  113.485229] Call trace:
[  113.487688]  __switch_to+0xec/0x1a8 (T)
[  113.491581]  __schedule+0x360/0xe18
[  113.495109]  schedule+0x34/0x110
[  113.498374]  schedule_timeout+0x84/0x100
[  113.502342]  rcu_gp_fqs_loop+0x114/0x420
[  113.506308]  rcu_gp_kthread+0x100/0x114
[  113.510188]  kthread+0x118/0x124
[  113.513466]  ret_from_fork+0x10/0x20
[  113.517082] rcu: Stack dump where RCU GP kthread last ran:
[  113.522566] Sending NMI from CPU 3 to CPUs 0:
[  186.553784] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  186.559904] rcu:     (detected by 3, t=41827 jiffies, g=3325, q=268 ncpus=4)
[  186.566706] rcu: All QSes seen, last rcu_preempt kthread activity 41829 (4294938937-4294897108), jiffies_till_next_fqs=1, root ->qsmask 0x0
[  186.579213] rcu: rcu_preempt kthread timer wakeup didn't happen for 41831 jiffies! g3325 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[  186.590599] rcu:     Possible timer handling issue on cpu=0 timer-softirq=1342
[  186.597556] rcu: rcu_preempt kthread starved for 41836 jiffies! g3325 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=0
[  186.607990] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[  186.617105] rcu: RCU grace-period kthread stack dump:
[  186.622155] task:rcu_preempt     state:R stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00000010
[  186.633219] Call trace:


I found out the the issue is related to the interrupt of the adv7535
bridge:

        adv7535: hdmi1@3d {
                compatible = "adi,adv7535";
                ...
                ...
                interrupts-extended = <&pinctrl RZG3E_GPIO(L, 4) IRQ_TYPE_EDGE_FALLING>;

RZ/G3E is using:
 - drivers/pinctrl/renesas/pinctrl-rzg2l.c

Reverting this patch fix the issue.
(git revert a23463beb3d5)

I'm wondering if someone else get the same.
Thanks in advance.

Kind Regards,
Tommaso


On Mon, Mar 09, 2026 at 02:49:15PM +0100, Oleksij Rempel wrote:
> In gpiochip_hierarchy_irq_domain_alloc(), calling irq_domain_set_info()
> before irq_domain_alloc_irqs_parent() causes a NULL pointer dereference
> for slow-bus (SPI/I2C) IRQ chips.
> 
> irq_domain_set_info() locks the child descriptor, triggering .irq_bus_lock.
> If the child proxies this lock to the parent, it crashes because
> parent->chip is not yet allocated.
> 
> Fix this by allocating the parent IRQs first, ensuring parent->chip is
> populated before the child's .irq_bus_lock is invoked.
> 
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> changes v3
> - new patch
> ---
>  drivers/gpio/gpiolib.c | 32 +++++++++++++++++---------------
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index ada572aaebd6..1ea9531934cc 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1628,19 +1628,6 @@ static int gpiochip_hierarchy_irq_domain_alloc(struct irq_domain *d,
>  	}
>  	gpiochip_dbg(gc, "found parent hwirq %u\n", parent_hwirq);
>  
> -	/*
> -	 * We set handle_bad_irq because the .set_type() should
> -	 * always be invoked and set the right type of handler.
> -	 */
> -	irq_domain_set_info(d,
> -			    irq,
> -			    hwirq,
> -			    gc->irq.chip,
> -			    gc,
> -			    girq->handler,
> -			    NULL, NULL);
> -	irq_set_probe(irq);
> -
>  	/* This parent only handles asserted level IRQs */
>  	ret = girq->populate_parent_alloc_arg(gc, &gpio_parent_fwspec,
>  					      parent_hwirq, parent_type);
> @@ -1657,12 +1644,27 @@ static int gpiochip_hierarchy_irq_domain_alloc(struct irq_domain *d,
>  	 */
>  	if (irq_domain_is_msi(d->parent) && (ret == -EEXIST))
>  		ret = 0;
> -	if (ret)
> +	if (ret) {
>  		gpiochip_err(gc,
>  			     "failed to allocate parent hwirq %d for hwirq %lu\n",
>  			     parent_hwirq, hwirq);
> +		return ret;
> +	}
>  
> -	return ret;
> +	/*
> +	 * We set handle_bad_irq because the .set_type() should
> +	 * always be invoked and set the right type of handler.
> +	 */
> +	irq_domain_set_info(d,
> +			    irq,
> +			    hwirq,
> +			    gc->irq.chip,
> +			    gc,
> +			    girq->handler,
> +			    NULL, NULL);
> +	irq_set_probe(irq);
> +
> +	return 0;
>  }
>  
>  static unsigned int gpiochip_child_offset_to_irq_noop(struct gpio_chip *gc,
> -- 
> 2.47.3
> 

  parent reply	other threads:[~2026-03-13 10:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 13:49 [PATCH v3 0/8] mfd: Add support for NXP MC33978/MC34978 MSDI Oleksij Rempel
2026-03-09 13:49 ` [PATCH v3 1/7] dt-bindings: mfd: add " Oleksij Rempel
2026-03-11  6:51   ` Krzysztof Kozlowski
2026-03-09 13:49 ` [PATCH v3 2/7] mfd: add NXP MC33978/MC34978 core driver Oleksij Rempel
2026-03-09 13:49 ` [PATCH v3 3/7] pinctrl: core: Make pin group callbacks optional Oleksij Rempel
2026-03-10  9:03   ` Linus Walleij
2026-03-09 13:49 ` [PATCH v3 4/7] gpio: gpiolib: fix allocation order in hierarchical IRQ domains Oleksij Rempel
2026-03-10  9:05   ` Linus Walleij
2026-03-10  9:14     ` Bartosz Golaszewski
2026-03-11  9:18       ` Bartosz Golaszewski
2026-03-11 13:40         ` Oleksij Rempel
2026-03-11 14:20           ` Bartosz Golaszewski
2026-03-13 10:42   ` Tommaso Merciai [this message]
2026-03-13 13:08     ` Oleksij Rempel
2026-03-13 13:52       ` Tommaso Merciai
2026-03-13 14:35         ` Bartosz Golaszewski
2026-03-14  7:08           ` Oleksij Rempel
2026-03-16  8:29             ` Bartosz Golaszewski
2026-03-09 13:49 ` [PATCH v3 5/7] pinctrl: add NXP MC33978/MC34978 pinctrl driver Oleksij Rempel
2026-03-10  9:09   ` Linus Walleij
2026-03-09 13:49 ` [PATCH v3 6/7] hwmon: add NXP MC33978/MC34978 driver Oleksij Rempel
2026-03-09 13:49 ` [PATCH v3 7/7] mux: add NXP MC33978/MC34978 AMUX driver Oleksij Rempel
2026-03-11 14:21 ` (subset) [PATCH v3 0/8] mfd: Add support for NXP MC33978/MC34978 MSDI Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abPqGvy5FqJ0a0ug@tom-desktop \
    --to=tommaso.merciai.xr@bp.renesas.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=conor+dt@kernel.org \
    --cc=david@protonic.nl \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=o.rempel@pengutronix.de \
    --cc=peda@axentia.se \
    --cc=robh@kernel.org \
    --cc=tomm.merciai@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.