Hi,

In a typical interrupt handling sequence we do

1-Read IAR

2-Do interrupt handling

3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC

>> I am suggesting a need of DSB here in case of GICv3 +.

4-Write to GIC cpu interface to do EOI.

Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The

Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be

generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from

core till peripheral which has to be dealt separately as per SOC.

Query: I understand GICv3 system interface accesses are not over this protocol and core will not

follow the ordering rule ?

I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in

RTOS environment where I have a primitive GICv3 driver but I wonder why things does

not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace

due to other device register writes then I would suggest to have one in the EOI clearing API itself.

RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454

Thanks

Sandeep