I don't understand this

As I explained in D478819: ARM's spec does not mandate/guarantee that the cache bits can be modified.

Therefore the value we write, be it zero in case of ITS_FLAGS_ERRATA_CAVIUM_22375 or RAWAWB otherwise, may not be what we read back.

QED: We should not ENXIO if the cache bits we read differ from the cache bits we wrote.

No, Andy’s point is the parentheses are in the wrong place so this is nonsensical.

Ok, where in the spec do you see that these bits can be read-only? I see that *OuterCache* is documented as potentially fixed, but there is no such note for *InnerCache* in my copy of IHI0069H.

What's the full output of acpidump -dt?

First and most importantly, I see it on this hardware where I cannot change the value of that field.

The spec doesn't say either way, all it says is that the field will have an "architecturally UNKNOWN value" on reset, but that does not actually promise that you can or should change that value.

For reference, Linux makes no attempt to modify that field, and I honestly dont see why we do ?

For OuterCache they had to explicitly talk about, because they changed their mind and have deprecated that field having a fixed value.

acpidump output at https://phk.freebsd.dk/misc/snapdragon_acpidump.txt (NB: impermanent link)

Linux does set it to the value it chooses and will fail to attach if that does not persist. https://github.com/torvalds/linux/blob/7f5b6a8ec18e3add4c74682f60b90c31bdf849f2/drivers/irqchip/irq-gic-v3-its.c#L2451-L2475

The implication is normally that all values are usable unless specified otherwise.

(Re Linux: See the ITS_FLAGS_FORCE_NON_SHAREABLE hack in line 2676, which explicitly triggers the exception in the code you quote.)

And I agree, I would expect the document to warn if a field or register might or might not be R/O or have restricted values.

And yet here we are:

GITS_BASER_CACHE_WAWB is not a value which can be written to that field on this hardware.

So we have evidence that either the documentation is not comprehensive, or there are silicon designers who read it differently than we do.

In either case, the hard failure is a bad idea, this machine would just have booted, if not for our unfounded hard failure.

And mind you, this was not easy to diagnose for me: The crucial printf did not even register on a 120fps camera, and it was not until I artificially slowed the console output down, that I was even able to see it.

I can live with that, I've debugged kernels with a single flashing LED as only output, but I believe in mending such potholethe, because the next unlucky pointer is probably not like me,

But I guess ... whatever... ?

I just need the first chunk of this patch and can we at least agree to commit that ?