[QUESTION] Possible ways of preventing GPIO probing

[Huichun Feng <foxhoundsk.tw@xxxxxxxxx>]

Hi,

I'm on a Xilinx UltraScale+ MPSoC SoC, and the kernel is v6.6.

It's a heterogeneous SoC including:

- Cortex-A53*4 (APU, Application Processing Unit)
- Cortex-R5*2 (RPU, Real-time Processing Unit)
- MicroBlaze based platform management unit (PMU)
- MicroBlaze based configuration security unit (CSU)

The SoC features a facility called Xilinx Peripheral Protection Unit
(XPPU), which prevents unintended access of GPIO (and the likes) from
particular processing units.

In my case, I found that Linux running on APU (A53 cores) attempts to
probe the GPIO used by the RPU (R5 cores), which requires the RPU to
do GPIO init again after the probe. Given this, I employ XPPU to
prevent Linux from accessing the GPIO [0], which seemingly works since
Linux then panic'd after the provisioning of XPPU. Following is the
panic message:

[    3.627182] SError Interrupt on CPU0, code 0x00000000bf000002 -- SError
[    3.627190] CPU: 0 PID: 32 Comm: kworker/u9:0 Not tainted
6.6.40-xilinx-g2b7f6f70a62a #1
[    3.627197] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
[    3.627201] Workqueue: events_unbound deferred_probe_work_func
[    3.627216] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    3.627223] pc : zynq_gpio_probe+0x1fc/0x3b4
[    3.627232] lr : zynq_gpio_probe+0x190/0x3b4
[    3.627238] sp : ffff8000819d3b60
[    3.627240] x29: ffff8000819d3b60 x28: ffff0008001dd0c0 x27: ffff000800011498
[    3.627250] x26: ffff0008001dd100 x25: ffff000800011400 x24: ffff00080372b0c0
[    3.627258] x23: ffff0008000fcc00 x22: 0000000000000001 x21: ffff0008000fcc10
[    3.627266] x20: ffff000802ea6880 x19: ffff000802ea6940 x18: ffffffffffffffff
[    3.627275] x17: ffff000800134c00 x16: ffff000800d3e000 x15: ffff8000819d3510
[    3.627284] x14: ffff00080002791c x13: ffff80008172b520 x12: 0000000000000019
[    3.627292] x11: ffff80008112cba0 x10: ffff84008349feaf x9 : 0000000000000028
[    3.627301] x8 : ffff00080372b120 x7 : 0000000000000000 x6 : 00000000552478d3
[    3.627309] x5 : 00000000ffffffff x4 : ffff800081d54000 x3 : ffff8000806a6d1c
[    3.627317] x2 : 0000000000000000 x1 : ffff800081d54354 x0 : ffff0008000fcc10
[    3.627326] Kernel panic - not syncing: Asynchronous SError Interrupt
[    3.627330] CPU: 0 PID: 32 Comm: kworker/u9:0 Not tainted 6.6.40
-xilinx-g2b7f6f70a62a #1
[    3.627335] Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
[    3.627338] Workqueue: events_unbound deferred_probe_work_func
[    3.627346] Call trace:
[    3.627349]  dump_backtrace+0x90/0xe8
[    3.627360]  show_stack+0x18/0x24
[    3.627369]  dump_stack_lvl+0x48/0x60
[    3.627379]  dump_stack+0x18/0x24
[    3.627387]  panic+0x314/0x370
[    3.627394]  nmi_panic+0x8c/0x90
[    3.627401]  arm64_serror_panic+0x6c/0x78
[    3.627407]  do_serror+0x28/0x68
[    3.627413]  el1h_64_error_handler+0x30/0x48
[    3.627423]  el1h_64_error+0x64/0x68
[    3.627429]  zynq_gpio_probe+0x1fc/0x3b4
[    3.627435]  platform_probe+0x68/0xc4
[    3.627443]  really_probe+0x148/0x2b0
[    3.627449]  __driver_probe_device+0x78/0x12c
[    3.627456]  driver_probe_device+0xd8/0x15c
[    3.627462]  __device_attach_driver+0xb8/0x134
[    3.627468]  bus_for_each_drv+0x88/0xe8
[    3.627473]  __device_attach+0xa0/0x190
[    3.627480]  device_initial_probe+0x14/0x20
[    3.627486]  bus_probe_device+0xac/0xb0
[    3.627492]  deferred_probe_work_func+0x88/0xc0
[    3.627498]  process_one_work+0x138/0x28c
[    3.627506]  worker_thread+0x2a4/0x4bc
[    3.627512]  kthread+0xe0/0xe4
[    3.627519]  ret_from_fork+0x10/0x20
[    3.627527] SMP: stopping secondary CPUs
[    3.627533] Kernel Offset: disabled
[    3.627535] CPU features: 0x0,00000008,00020000,0000420b
[    3.627540] Memory Limit: none
[    3.885271] ---[ end Kernel panic - not syncing: Asynchronous
SError Interrupt ]---

At the moment of the panic, which is just after the employment of the
XPPU, I thought that I should disable the GPIO in devicetree. However,
after the GPIO got disabled [1], the panic still present.  Is it
because that, in this case, I can't simply disabling the GPIO through
adding 'status="disable";' ?

If there's any RTFM thing I should do beforehand, please provide me
some keywords or in-tree document names.

[0] I believe this is simply an initial step since I would also need
to teach Linux not to use/probe this particular GPIO.
[1] I can assure that the GPIO does get disabled since it was a
heartbeat LED for Linux, which no longer beats/flashes after the
devicetree disable thing.

Thanks!
Fox