The its-trigger test checks that LPI 8195 is not delivered to the CPU while
it is disabled at the ITS level. After that it is re-enabled and the test
checks that the interrupt is properly asserted. After it's re-enabled and
before the stats are examined, the test triggers the interrupt again, which
can lead to the same interrupt being delivered twice: once after the
configuration invalidation and before the INT command, and once after the
INT command.
Add an explicit check that the interrupt has fired after the invalidation.
Leave the check after the INT command to make sure the INT command still
works for the now re-enabled LPI.
CC: Auger Eric <eric.auger@xxxxxxxxxx>
Suggested-by: Zenghui Yu <yuzenghui@xxxxxxxxxx>
Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
Reviewed-by: Eric Auger <eric.auger@xxxxxxxxxx>
Signed-off-by: Alexandru Elisei <alexandru.elisei@xxxxxxx>
---
arm/gic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arm/gic.c b/arm/gic.c
index af2c112336e7..8bc2a35908f2 100644
--- a/arm/gic.c
+++ b/arm/gic.c
@@ -802,6 +802,9 @@ static void test_its_trigger(void)
/* Now call the invall and check the LPI hits */
its_send_invall(col3);
+ lpi_stats_expect(3, 8195);
+ check_lpi_stats("dev2/eventid=20 pending LPI is received");
+
lpi_stats_expect(3, 8195);
its_send_int(dev2, 20);
check_lpi_stats("dev2/eventid=20 now triggers an LPI");
--
2.30.1
