Re: [PATCH v2 00/24] ARM: zte: Add support for Sanechips ZX279128S and ZTE ZXHN H3600

[Agustin Santiago Isasmendi <isasmendi.agus@gmail.com>]

Hi Stefan,

On Sun, 8 Nov 2026, Stefan Dösinger wrote:
> However, Arnd Bergmann didn't like the hack and it looks like we don't
> understand what exactly is going on, so they agreed to postpone this
> particular issue for now (see follow-up replies in the linked thread). If you
> have further ideas what ZTE got wrong in the hardware and what kind of
> workaround they use that would be helpful

Thanks, I had missed that thread.  The RFC I mentioned was the same
lock, so I will not send it.  Here is what I know so far, from my H3600
on Navid's v2.

What ZTE does (from their 4.1.25 kernel binary): l2x0_lock is taken
around every line write of the L2C range operations and around the
Cache Sync, and around every register read of their mt7915 driver
(through an exported fixed_pci_read_u32()).  A later module only makes
the lock finer: the range ops drop it every 2 KiB, and a pending PCIe
read makes them drop it early.  I found no chicken bit: their L2C
setup matches ours and their PCIe init has no such setting.

What goes wrong: a PCIe read on one CPU deadlocks against an L2C-310
line operation by PA or a Cache Sync on the other.  The TRM (DDI
0246H, 3.3.10) says those operations stall the L2C slave ports until
they complete, and here the PCIe read apparently cannot complete
meanwhile.  3 boots x 8 minutes of WiFi traffic each:

  no workaround                              hang 3/3
  maxcpus=1                                  ok 3/3
  arm,outer-sync-disable                     hang 3/3
  lock around the Cache Sync only            hang 3/3
  lock around the range ops only             hang 3/3
  lock on the L2C side only, reads unlocked  hang 3/3
  lock on both sides (as ZTE)                ok 3/3
  dma-coherent                               firmware load fails

So PCIe DMA is not coherent and the maintenance has to stay.

A possible way forward: Arnd's fallback of SMP with the L2 off works,
no hang in 3 boots x 8 minutes (75 transfers).  It cannot be done from
the DT today, because l2x0_of_init() ignores status = "disabled"; I
had to change the compatible for the test.  So I would suggest:

- a small patch so that l2x0_of_init() honours the status property
  (no in-tree PL310 node is disabled, so nothing else changes);
- Navid's DT disables the L2C, so mainline is stable with WiFi;
- the lock stays downstream in OpenWrt until there is a better fix.

I haven't measured the cost of the L2 off properly yet; I can do that
if this direction sounds reasonable.

Cheers,
Agustin