Re: [PATCH v3] irqchip/riscv-aplic: fix asynchronous probing

[Vladimir Kondratiev <Vladimir.Kondratiev@mobileye.com>]

On 10/15/26 12:56, Sebastian Andrzej Siewior wrote:
> EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
> 
> On 2026-10-15 11:11:24 [+0300], Vladimir Kondratiev wrote:
>> On 10/15/26 09:32, Sebastian Andrzej Siewior wrote:
>>> The driver providing MSI capabilities (the MSI domain for this device)
>>> must a module. This is the requirement so that _this_ driver returns
>>> EPROBE_DEFER and *then* once the MSI domain driver is loaded as a module
>>> (after boot) this driver is probed again and succeeds.
>> Why module? for "riscv-aplic", "msi-parent" shall be "riscv-imsic" and
>> it is "builtin_platform_driver", see
>> drivers/irqchip/irq-riscv-imsic-platform.c
> 
> But _how_ do you want to make deferred probing happen that will change
> aplic_syscore_registered after init without using modules?
> 

This is how. I provide a counter-example. To model supplier that will
not be satisfied I added fake "clocks". I know there's no "clocks" in
the aplic bindings, this is simply to model supplier that takes long
time. In the real life it should be the msi-parent that takes forever to
probe.

DTS modified like this, it has 3 aplic_m/aplic_s pairs, I show here only
modifications:

/ {
	soc {
		aplic_late_supplier: aplic-late-supplier {
			compatible = "test,aplic-late-supplier";
			#clock-cells = <0>;
		};
	};
};
&aplic_s0 { clocks = <&aplic_late_supplier>; };
&aplic_s1 { clocks = <&aplic_late_supplier>; };
&aplic_s2 { clocks = <&aplic_late_supplier>; };
&aplic_m0 { clocks = <&aplic_late_supplier>; };
&aplic_m1 { clocks = <&aplic_late_supplier>; };
&aplic_m2 { clocks = <&aplic_late_supplier>; };

It fails on boot, real test with QEMU:

[    1.940204] Freeing unused kernel image (initmem) memory: 2328K
[    1.940774] Run /init as init process
[   10.874635] riscv-aplic 48760000.interrupt-controller: 257 interrupts
directly connected to 8 CPUs
[   10.874892] Unable to handle kernel paging request at virtual address
ffffffff80e04fc4
[   10.875059] [ffffffff80e04fc4] pgd=000000023fffe801,
p4d=000000023fffe801, pud=000000023fffe801, pmd=00000002004000e3
[   10.875407] Oops [#1]
[   10.875806] Workqueue: events_unbound deferred_probe_work_func
[   10.875961] epc : aplic_probe+0xd8/0xfa
[   10.876153] status: 0000000200000120 badaddr: ffffffff80e04fc4 cause:
000000000000000f
[   10.876210] [<ffffffff804ca134>] aplic_probe+0xd8/0xfa
[   10.876252] [<ffffffff80559b4e>] platform_probe+0x3e/0x7a
[   10.876262] [<ffffffff8055733a>] really_probe+0x88/0x35c
...
[   10.876349] [<ffffffff80556f9a>] deferred_probe_work_func+0x92/0xfe
[   10.876360] [<ffffffff800448aa>] process_one_work+0x150/0x3d4

cause: 0xf is a store page fault; the PMD 0x...e3 has V|R|X|A|D but not
W, i.e. the rodata mapping after mark_rodata_ro(). The faulting
instruction is the store from aplic_syscore_init() (inlined into
aplic_probe):

ffffffff804ca12a:	jal	ffffffff80558216 <register_syscore>
ffffffff804ca12e:	li	a5,1
ffffffff804ca130:	auipc	a4,0x93b
ffffffff804ca134:	sb	a5,-364(a4) # ffffffff80e04fc4
<aplic_syscore_registered>