Re: [PATCH 02/24] ARM: l2c: Serialize device reads with cache maintenance when requested

["Arnd Bergmann" <arnd@arndb.de>]

On Sun, Oct 11, 2026, at 03:02, Navid Ghahremani wrote:
>
> Thank you again for the suggestion to test arm,outer-sync-disable. I 
> have now completed extensive hardware tests on the physical ZTE ZXHN 
> H3600 across multiple bring-up orders and load scenarios, and 
> unfortunately disabling outer-sync alone is not sufficient to prevent 
> the interconnect deadlock.
>
> Here is what I tested:
> 1. Added arm,outer-sync-disable to the l2cc node in the device tree 
> (zx279128s.dtsi).
> 2. Rebuilt the kernel with CONFIG_CACHE_L2X0_IO_LOCK disabled and 
> completely removed my custom read lock from both cache-l2x0 and mt76.
> 3. Netbooted the initramfs uImage over TFTP into RAM via U-Boot (zero 
> flash modification).
>
> The kernel booted cleanly and confirmed the configuration:
> [    0.000000] L2C: disabling outer sync
> [    0.000000] L2C-310 cache controller enabled, 16 ways, 256 kB
>
> Both MT7915 cards enumerated over PCIe and initialized firmware. Here 
> are the observed results across the different test scenarios:

Thanks for the detailed testing!

> Given that this is a silicon crossbar flaw that requires software 
> serialization, what would you recommend as the cleanest, most 
> acceptable way to structure this for upstream? Would you prefer keeping 
> the serialization lock as an SoC-specific quirk in cache-l2x0, or is 
> there an alternative architectural mechanism you would suggest?

The best idea I have so far is to delay solving this problem and
just upstream the patches that are not impacted by it for the moment.
Even if you never upstream patches 2 and 3, that would still
get you much closer to something that works out of the box.

My hope would be that there is some errata workaround that you
can simply turn on with a chicken bit in the firmware, but if the
vendor BSP has the same approach as you tried here, that seems
a lot less likely.

You can also try to avoid the issue in a way that trades it for
overall performance, e.g. using only one CPU and turning off
the L2 coherency management in the CCU, or leaving SMP enabled
but turning off the L2 cache. Not sure if either approach would
work at all, and the performance cost may make this impractical.
At least it would give you something that works reliably
while you can still use a patched kernel for better performance.

One possible idea would be to use the helpers from
lib/logic_iomem.c to register a special MMIO range that takes
care of PCI MMIO regardless of the PCI device driver. This seems
like a cleaner approach, but I cannot guarantee that any patches
for this would find consensus.

      Arnd