Hi,
On 1/29/21 5:36 PM, Alexandru Elisei wrote:
> 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>
> Signed-off-by: Alexandru Elisei <alexandru.elisei@xxxxxxx>
Reviewed-by: Eric Auger <eric.auger@xxxxxxxxxx>
Eric
> ---
> 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");
>
