On Tue, Sep 13, 2016 at 2:52 PM, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > [Me] >> 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"? 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. 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 */ Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html