Hi Mika,

On Tue, Jun 2, 2015 at 4:15 PM, Mika Westerberg
[off-list ref] wrote:

On Tue, Jun 02, 2015 at 03:53:40PM +0200, Linus Walleij wrote:

quoted

On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg
[off-list ref] wrote:

quoted

On Fri, May 22, 2015 at 10:56:08AM +0300, Mika Westerberg wrote:

quoted

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@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

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.

Did you find a way to fix this issue ? I'm seeing a similar problem on a
laptop where this masks the interrupt used for ACPI events (brightness,
lid, battery).

Regards,

Anisse