Mika Westerberg <mika.westerberg <at> linux.intel.com> writes:

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
<mika.westerberg <at> linux.intel.com> 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

quoted

quoted

quoted

(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

quoted

quoted

quoted

to clear the status register.

Reported-by: Yu C Chen <yu.c.chen <at> intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg <at> 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.

Are there any updates on this problem? I came through this while doing
hardware enablement for a laptop, and the symptoms were the brightness
control keys stop working when this module was loaded. This patch fixes the
problem on that specific platform.

I'm happy to test or help out with a better suited fix if given some guidance.

Best regards,

PS: please keep me copied in the thread since I do not sign linux-gpio nor LKML.

--
João Paulo Rechi Vita
http://about.me/jprvita