Fix endianness on FDT read in ARM GIC

[zbb]

Summary

Submitted by: Jakub Palider <[e-mail]>
Obtained from: Semihalf

[skra]

In fact, the opposite is correct. In present, the arguments passed to function are already in suitable format. So, all fdt32_to_cpu() calls should be removed. I remembered some debate with Michal about that that only consumer knows what kind of data come to him, so decoding should be done on his side entirely. However, in current tree, the data are decoded in ofw_bus_intr_to_rl().

[skra]

Well, Michal pointed me that it works in currnet. So, the true is that interrupt cells are now decoded in ofw_bus_intr_to_rl(), then again in arm_fdt_map_irq(), and then again in gic_decode_fdt(). So I was wrong. However, doing cpu_to_fdt32() three times on same data is not good too.

[zbb]

Yes that is the case here.
We suggest to commit this patch now and think about fixing arm_fdt_map_irq() (and other intr mapping routines) later.
Is there any sense to improve intr.c now (intr_ng is going to replace it)?

[nwhitehorn]

This is a good patch. The spec defines that interrupts properties are in 32-bit chunks "encoded as with <encode-int>" (i.e. big-endian and 32-bits at a time), so all endian decoding should be confined to OF_getencprop() calls in ofw_bus_intr_to_rl().

[• ian]

This looks right to me (but then... I'm the one who screwed it up in the first place, so don't take my word for it).

I agree that triple-reversing the endianess is strange and we should make sure we get that fixed in intrng.

[zbb]

Thanks! Committed to: 279235

https://svnweb.freebsd.org/changeset/base/279235