[PATCH v3] irqchip/riscv-aplic: fix asynchronous probing
Vladimir Kondratiev
Vladimir.Kondratiev at mobileye.com
Thu Oct 15 06:52:51 PDT 2026
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>
More information about the linux-riscv
mailing list