On Tue, Sep 13, 2016 at 10:57:31PM +0200, Linus Walleij wrote:

On Tue, Sep 13, 2016 at 2:52 PM, Mika Westerberg
[off-list ref] wrote:

quoted

[Me]

quoted

A-ha! But why are you registering a irqdomain entry for an interrupt
that cannot be used, hm?

Unfortunately there is no way to figure out from the hardware (or
firmware) whether the interrupt is supposed to be used by the GPIO
driver or something else.

So the fact that we kept it in valid-mask in the DT was a hint: it is
part of the hardware description.

Isn't this (a list of what IRQs are reserved by BIOS) by sheer logic
something that ACPI should provide?

Or is this one of those "well we could alter ACPI tables but we can't
because they already shipped so we just can't so now we need to
hack around it"?

Isn't it always the case? ;-)

Once the hardware enters stores the firmware cannot be changed anymore
and we get all the fun working around problems in the OS.

Letting Linux map an interrupt it cannot access and then papering it
over by using handle_simple_irq() just feels wrong to me.

I would argue for associating the mask of BIOS-reserved IRQs with
something in ACPI and implement the mentioned scheme to avoid
even mapping them seems most logical.

I'm going to re-read the hardware spec and see if there is anything we
can do about this. The newer hardware (Skylake, Broxton) has a bit that
tells the IRQ is routed directly to I/O-APIC but unfortunately Braswell
misses that. There may be something else, though.

If we have to use handle_simple_irq() by default on all I prefer to put
in a very fat comment of the type:

/*
 * HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK
 *
 * Some interrupts are BIOS-reserved but we don't know which ones!
 * So we anyway map them and assign the handle_simple_irq() handle
 * to them, leaving them unmasked, pretending they can be used, and
 * pray no-one will accidentally use these GPIO IRQs.
 *
 * HACK HACK HACK HACK HACK HACK HACK HACK HACK HACK
  */

OK, got it.

Let me try to come up with a solution that both works and does not
involve using handle_simple_irq.