Re: [PATCH] ARM: exynos: Rework system wakeup interrupts initialization

[Krzysztof Kozlowski <krzk@kernel.org>]

On 18/11/2025 14:21, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> CC Robh
> 
> On Tue, 18 Nov 2025 at 12:50, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> Since commit 1b1f04d8271e ("of/irq: Ignore interrupt parent for nodes
>> without interrupts") it is not possible to get parent interrupt device
>> node when no 'interrupts' property is specified. Rework the hack used for
>> initializing the Exynos system wakeup interrupts (PMU controller is a
>> proxy for SoC RTC interrupts) to get the parent interrupt node by
>> manually parsing 'interrupt-parent' property.
>>
>> Fixes: 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains")
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> 
> Thanks for your patch!
> 
>> ---
>> This fixes the following boot failure of allmost all ARM 32bit Exynos
>> boards observed since next-20251118:
>>
>> /soc/system-controller@10020000: no parent, giving up
>> OF: of_irq_init: Failed to init /soc/system-controller@10020000 ((ptrval)), parent 00000000
> 
> Oops...
> 
>> ...
>> 8<--- cut here ---
>> Unable to handle kernel paging request at virtual address 00002008 when read
>> [00002008] *pgd=00000000
>> Internal error: Oops: 5 [#1] SMP ARM
>> Modules linked in:
>> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1-00026-g1b1f04d8271e #16162 PREEMPT
>> Hardware name: Samsung Exynos (Flattened Device Tree)
>> PC is at exynos_set_delayed_reset_assertion+0x5c/0xb0
>> LR is at exynos_set_delayed_reset_assertion+0x80/0xb0
>> pc : [<c012b9a4>]    lr : [<c012b9c8>]    psr: 80000053
>> ...
>> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
>> Stack: (0xf0825f30 to 0xf0826000)
>> ...
>> Call trace:
>>  exynos_set_delayed_reset_assertion from exynos_smp_prepare_cpus+0x10/0x34
>>  exynos_smp_prepare_cpus from kernel_init_freeable+0x94/0x234
>>  kernel_init_freeable from kernel_init+0x1c/0x12c
>>  kernel_init from ret_from_fork+0x14/0x28
>> Exception stack(0xf0825fb0 to 0xf0825ff8)
>> ...
>> ---[ end trace 0000000000000000 ]---
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>
>> Best regards
>> Marek Szyprowski, PhD
>> Samsung R&D Institute Poland
>> ---
>>  arch/arm/mach-exynos/suspend.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
>> index 44811faaa4b4..02785342e0c7 100644
>> --- a/arch/arm/mach-exynos/suspend.c
>> +++ b/arch/arm/mach-exynos/suspend.c
>> @@ -192,6 +192,7 @@ static int __init exynos_pmu_irq_init(struct device_node *node,
>>  {
>>         struct irq_domain *parent_domain, *domain;
>>
> 
> Perhaps add a check:
> 
>     if (!parent)
> 
> just in case any of the pmu system controllers ever gets a real
> interrupts or interrupts-extended property?
> 
>> +       parent = of_parse_phandle(node, "interrupt-parent", 0);
> 
> Or of_irq_find_parent(node)?
> 
>>         if (!parent) {
>>                 pr_err("%pOF: no parent, giving up\n", node);
>>                 return -ENODEV;

Ack for both and also please of_node_put in the error paths, which will
be a bit complicated if parent can be non-NULL as well.

I wonder now whether more platforms are affected, e.g. imx_gpc_init().
See also Mark's report.

https://lore.kernel.org/all/b037f67a-b241-4689-9914-57ff578c1454@sirena.org.uk/


Best regards,
Krzysztof