From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759126AbbFBOP7 (ORCPT ); Tue, 2 Jun 2015 10:15:59 -0400 Received: from mga02.intel.com ([134.134.136.20]:4614 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759135AbbFBOPn (ORCPT ); Tue, 2 Jun 2015 10:15:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,540,1427785200"; d="scan'208";a="719346816" Date: Tue, 2 Jun 2015 17:15:20 +0300 From: Mika Westerberg To: Linus Walleij Cc: Heikki Krogerus , Yu C Chen , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Message-ID: <20150602141520.GE4057@lahna.fi.intel.com> References: <1432281368-88687-1-git-send-email-mika.westerberg@linux.intel.com> <20150601092348.GK1747@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 02, 2015 at 03:53:40PM +0200, Linus Walleij wrote: > On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg > 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 > >> Signed-off-by: Mika Westerberg > > > > 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.