While not trying to malign anybody, I am curious to learn if it is
possible that the AUX_NIRQ interrupt on the balloon3 board has never
been adequately tested.

I ask because some of the code I see in arch/arm/mach-pxa/balloon3.c
looks just plain wrong, and because, right or wrong (I haven't even
gotten to that code yet), I can't seem to get my FPGA to generate an
interrupt that is serviced by my kernel.

I will debug this problem differently depending on whether I should
assume that the code is known to work than I would if I don't have
that up front knowledge.

The questionable code looks like:

static void balloon3_irq_handler(unsigned int irq, struct irq_desc *desc)
{
	unsigned long pending = __raw_readl(BALLOON3_INT_CONTROL_REG) &
					balloon3_irq_enabled;
	do {
		/* clear useless edge notification */
		if (desc->chip->ack)
			desc->chip->ack(BALLOON3_AUX_NIRQ);
		while (pending) {
			irq = BALLOON3_IRQ(0) + __ffs(pending);
			generic_handle_irq(irq);
			pending &= pending - 1;
		}
		pending = __raw_readl(BALLOON3_INT_CONTROL_REG) &
				balloon3_irq_enabled;
	} while (pending);
}

The part that confuses me however is the line that reads:

pending &= pending - 1;

Shouldn't that be more like:

pending &= ~(1 << (irq - BALLOON3_IRQ(0)))

(I wouldn't do it exactly that way, but I'm just trying to make a point here).

Feel free to tell me the code works fine in millions of applications
worldwide, and I'll continue down the path of assuming balloon3.c is
correct and my code is wrong.

If I don't hear from anybody, I'm going to start assuming that
balloon3.c is questionable, fix things the way I think they should be
fixed, and submit a patch to the list.

Oh yeah, for purely hysterical reasons, I'm working with the 2.6.37.6
kernel from the stock balloonboard tree, if that makes any difference.

--wpd