Re: [PATCH RFC 0/2] PCI: rockchip-host: Retry training and hot-reset a JMB585 on RK3399

["Enrique Hernández Bello" <ehbello@gmail.com>]

You said both SErrors and synchronous external aborts occur. In my logs which
of the two you get tracks the cluster the access runs on, which might be worth
a look before you move the hook.

Every asynchronous SError in rockchip_pcie_rd_conf landed on CPU4 or CPU5, the
A72s, across six boots on two different kernels. The one time the same read
aborted synchronously it was on CPU3, an A53. They also carry different ISS:
0xbf000002 for these config-read aborts, against 0xbf000000 for the unrelated
runtime SErrors on this board.

That is one synchronous case, so not a law, but it is cheap for you to test:
pin enumeration to an A53 and see whether your aborts all become synchronous.

It matters because only the synchronous form can be repaired. When it arrives
as an SError the load has retired and there is no destination register left to
write all-ones into, so no fixup can help.

I prototyped the synchronous half in September: an exception-table entry
consulted from do_sea(), with the driver substituting the all-ones the PCI core
expects rather than only surviving. arm32 has had that for years --
imx6q_pcie_abort_handler() in dwc/pci-imx6.c decodes the faulting instruction
and makes a read look like all-ones, under #ifdef CONFIG_ARM -- and arm64 has
no equivalent path. It only ever worked for me with enumeration pinned to an
A53, which is what made me look at the cluster in the first place.

Not proposing anything, and not reviving that prototype. Yours if any of it
is useful.