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

["Stefan Dösinger" <stefandoesinger@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

Hi,

Am Dienstag, 10. November 2026, 18:35:22 Ostafrikanische Zeit schrieb Agustin 
Santiago Isasmendi:

> 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.

I haven't dealt with caches or PCI myself, so I have some clueless questions:

Is it possible to program PCIe mmio areas as uncached in the level 2 cache or 
tell the cache to ignore a certain address range in some way? If it is 
possible, is it enough to prevent the crash?

Do you have a guess what's special about the PCI address space that it 
triggers the issue? It sounds like it doesn't affect other hardware or RAM, 
otherwise ZTE would have disabled (or just fixed) the cache entirely.

> 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:

What does "TRM" mean in this context?

As for the patches you sent separately: I can't say much about them since I 
don't know the pl-310 cache controller. I guess I am also lucky that my board 
has only once CPU :-)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]