rk3399 fails to boot since v6.12.7

[Christoph Fritz]

Hello Marc,

 since 773c05f417fa1 ("irqchip/gic-v3: Work around insecure GIC
integrations") landed in stable v6.12.7 as 0bf32f482887, here the
rk3399 fails to boot (~4 out of 10 times) because OP-TEE panics (gets a
secure interrupt that it cannot handle).

Setup is:
 - BL31 proprietary (since mainline TF-A has no DMA)
 - OP-TEE mainline version: 3.20
 - Kernel v6.12.7

<snip>
[    0.000000] GICv3: Broken GIC integration, security disabled
<snip>
E/TC:4 0 Panic 'Secure interrupt handler not defined' at core/kernel/interrupt.c:139 <itr_core_handler>
E/TC:4 0 TEE load address @ 0x30000000
E/TC:4 0 Call stack:
E/TC:4 0  0x300091f8
E/TC:4 0  0x30016664
E/TC:4 0  0x30015710
E/TC:4 0  0x30005714
[   26.087363] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   26.087925] rcu:     (detected by 2, t=21002 jiffies, g=2233, q=2416 ncpus=6)
[   26.088530] rcu: All QSes seen, last rcu_preempt kthread activity 21002 (4294693363-4294672361), jiffies_till_next_fqs=3, root ->qsmask 0x0
[   26.089623] rcu: rcu_preempt kthread timer wakeup didn't happen for 20999 jiffies! g2233 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200
[   26.090617] rcu:     Possible timer handling issue on cpu=4 timer-softirq=293
[   26.091218] rcu: rcu_preempt kthread starved for 21002 jiffies! g2233 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=4
[   26.092131] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
[   26.092926] rcu: RCU grace-period kthread stack dump:
[   26.093369] task:rcu_preempt     state:R stack:0     pid:16    tgid:16    ppid:2      flags:0x00000008
[   26.094192] Call trace:
[   26.094409]  __switch_to+0xf0/0x14c
[   26.094728]  __schedule+0x264/0xa90
[   26.095040]  schedule+0x34/0x104
[   26.095329]  schedule_timeout+0x80/0xf4
[   26.095672]  rcu_gp_fqs_loop+0x14c/0x4a4
[   26.096027]  rcu_gp_kthread+0x138/0x164
[   26.096369]  kthread+0x114/0x118
[   26.096661]  ret_from_fork+0x10/0x20
[   26.096982] rcu: Stack dump where RCU GP kthread last ran:
[   26.097463] Sending NMI from CPU 2 to CPUs 4:
[   46.276364] sched: DL replenish lagged too much

Is it too late for the kernel to disable the "security" since OP-TEE
assumes it is enabled?

Any ideas?

Thanks
  -- Christoph