On Tue, Jun 02, 2015 at 03:53:40PM +0200, Linus Walleij wrote: > On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > On Fri, May 22, 2015 at 10:56:08AM +0300, Mika Westerberg wrote: > >> BIOS/platform may use some of the pins by themselves, such as providing SCI > >> (System Control Interrupt) from the embedded controller. The driver masks > >> all interrupts at probe time which prevents those pins from triggering > >> interrupts properly. > >> > >> Fix this by not masking all interrupts at probe -- it should be enough just > >> to clear the status register. > >> > >> Reported-by: Yu C Chen <yu.c.chen@xxxxxxxxx> > >> Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > > > Please ignore this patch for now. It turned out to be causing spurious > > interrupts on another platform. > > > > I'll need to rethink how to fix the reported issue. > > Looks like a case of "embed more magic knowledge" in the driver :/ > > It needs to know what platform it is running on, and only leave specific > bits unmasked on these specific platforms. Right? Thereby > tossing all of the acpi_device_id matching and abstraction out > of the window. That's right. We still have few options left, like using ACPI _AEI (ACPI GPIO triggered events) for this or adding GPIO interrupt support directly to the EC driver. -- 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