Sergei,

On 28-02-2011 16:33, Will Deacon wrote:

quoted

The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent
chip prior to handling the interrupt.

quoted

This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.

quoted

Acked-by: Colin Cross<redacted>
Signed-off-by: Will Deacon<redacted>
---
  arch/arm/mach-tegra/gpio.c |   17 +----------------
  1 files changed, 1 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
index ad80488..5019b01 100644
--- a/arch/arm/mach-tegra/gpio.c
+++ b/arch/arm/mach-tegra/gpio.c

@@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
  	struct tegra_gpio_bank *bank;
  	int port;
  	int pin;
-	int unmasked = 0;
-
-	desc->irq_data.chip->irq_ack(&desc->irq_data);

    Won't this code break after the first patch as it removes irq_ack()
method? I.e. shouldn't the patches be combined to keep them bisectable?

If you read the cover letter, I said:

This is going to be a PITA to merge so any thoughts relating to that
are welcome.

I'm aware of the bisecting issues and Russell has come up with a solution
using entry/exit functions to sort this out (with the GIC changes moved to
the end of the series).

But we have bigger fish to fry.

The whole question about whether or not chained handlers should be written
with multiple parent chips in mind is a hot topic. Thomas has some interesting
ideas for the core code which will allow the chained handler not to care about
flow control. Once we've sorted out the mechanism for this stuff, the merging
should be fairly straightforward because the chip details will be irrelevant.

Will