BACKPORT: FROMGIT: irqchip/gic-v2, v3: Implement irq_chip->irq_retrigger()

While digging around IRQCHIP_EOI_IF_HANDLED and irq/resend.c, it has come
to my attention that the IRQ resend situation seems a bit precarious for
the GIC(s).

When marking an IRQ with IRQS_PENDING, handle_fasteoi_irq() will bail out
and issue an irq_eoi(). Should the IRQ in question be re-enabled,
check_irq_resend() will trigger a SW resend, which will go through the flow
handler again and issue *another* irq_eoi() on the *same* IRQ
activation. This is something the GIC spec clearly describes as a bad idea:
any EOI must match a previous ACK.

Implement irq_chip.irq_retrigger() for the GIC chips by setting the GIC
pending bit of the relevant IRQ. After being called by check_irq_resend(),
this will eventually trigger a *new* interrupt which we will handle as usual.

Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200730170321.31228-2-valentin.schneider@arm.com

Bug: 140053385
(cherry picked from commit 17f644e9
 https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git

 irq/gic-retrigger)
(resolved trivial merge conflict in drivers/irqchip/irq-gic.c)
Change-Id: I1c5e81c7cf33155e81ba31615e5eaf3f578350c2
Signed-off-by: Eric Biggers <ebiggers@google.com>