Re: [RFC PATCH 3/3] gpio: mb86s70: enable ACPI and irqchip support
diff --git a/m b/m
index 939f842..0e2c11f 100644
--- a/m
+++ b/m
@@ -2,69 +2,84 @@
 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
 	aws-us-west-2-korg-lkml-1.web.codeaurora.org
 X-Spam-Level: 
-X-Spam-Status: No, score=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
-	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
-	SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham
-	autolearn_force=no version=3.4.0
+X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
+	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,
+	SPF_PASS autolearn=ham autolearn_force=no version=3.4.0
 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
-	by smtp.lore.kernel.org (Postfix) with ESMTP id 7AEF4C43219
-	for <infradead-linux-arm-kernel@archiver.kernel.org>; Thu, 25 Apr 2019 13:35:59 +0000 (UTC)
+	by smtp.lore.kernel.org (Postfix) with ESMTP id 66FB6C43218
+	for <infradead-linux-arm-kernel@archiver.kernel.org>; Thu, 25 Apr 2019 13:36:49 +0000 (UTC)
 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133])
 	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 	(No client certificate requested)
-	by mail.kernel.org (Postfix) with ESMTPS id 4091D206BF
-	for <infradead-linux-arm-kernel@archiver.kernel.org>; Thu, 25 Apr 2019 13:35:59 +0000 (UTC)
+	by mail.kernel.org (Postfix) with ESMTPS id 24E01206BF
+	for <infradead-linux-arm-kernel@archiver.kernel.org>; Thu, 25 Apr 2019 13:36:49 +0000 (UTC)
 Authentication-Results: mail.kernel.org;
-	dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZSu4t3YI"
-DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4091D206BF
-Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com
+	dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Zr8szpnH";
+	dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="IHtyeunP"
+DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24E01206BF
+Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org
 Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org
 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 	d=lists.infradead.org; s=bombadil.20170209; h=Sender:
 	Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:
-	List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:
-	Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:
+	List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:
+	In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description:
 	Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
-	List-Owner; bh=BAS5EStilF106yqoE7eKs/vY6onl2UZDERaQTNLaMR8=; b=ZSu4t3YI7zJBhA
-	0NCCHQPKWHR2cAaih+DjfkSWmeKsPqRuENUkfWGBx8VOadhjmCoKCUsVu03J2msMrrjIW4b2jBwqb
-	K1Ssfs0WZgkoUPTaQaYyiwVO2G/rrH0w+07YxyyhQvsq4CA6YXfnJlyIkkwoDU4um4Mwjn+zZO260
-	vqtiNuJ/992FuJ5LEmhya0Kh5Yka+L+iWWTTinWPpYgwyFto2qxkAdANxAaIPbDX8hQoP5bYbvVs8
-	n5S3yMeKtitYb+lEKw29xeuPghOAA0FHnVYfnsgo0CNXEcPqFNqH1aBQyVqEXNuAAy18oxmEwZiX4
-	p8kpasvfdcOjMJZ/1F0g==;
+	List-Owner; bh=a1TpNC3N9oLuvq2SE81KEIINtNuWWzaYyLgK9QZAwks=; b=Zr8szpnHTaSWj9
+	ZmTv0hquE/gqL0p5Sbn/7OOrajDmXFR6bU0pPSRE74Zo8wthMHb4Y3pILcN43NeDkzA1ZBAyEoEDe
+	EaWnYeIX0j1BMTq134NQQDV6PGpIsJxWeMFeMRzW1w2dc6sT0vACDn3rGROl1cc4MAO8lz2f24ZUC
+	QsGwWOVLNzvf9gS1zf5L401QPn/hHXgxnPax631DrbOccL+LToAbwyPeI95T+h5L+tC/41FwEKg5i
+	imVB0JIzcaaeur0pnIdHhsOn5+KhHAiyrO5liCLPBPcn11xaLn/PJqF/vNt6a/UiLVBUe4n/9j1NB
+	zsDJumoVa6D7+aPdckIA==;
 Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org)
 	by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux))
-	id 1hJeXZ-0000hp-97; Thu, 25 Apr 2019 13:35:53 +0000
-Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]
- helo=foss.arm.com)
- by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux))
- id 1hJeWt-00083l-4J
- for linux-arm-kernel@lists.infradead.org; Thu, 25 Apr 2019 13:35:16 +0000
-Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])
- by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E4CAA78;
- Thu, 25 Apr 2019 06:35:10 -0700 (PDT)
-Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com
- [10.72.51.249])
- by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 892903F5C1;
- Thu, 25 Apr 2019 06:35:08 -0700 (PDT)
-Date: Thu, 25 Apr 2019 14:35:06 +0100
-From: Dave Martin <Dave.Martin@arm.com>
-To: Alex =?iso-8859-1?Q?Benn=E9e?= <alex.bennee@linaro.org>
-Subject: Re: [PATCH v7 13/27] KVM: arm64/sve: Context switch the SVE registers
-Message-ID: <20190425133505.GD3567@e103592.cambridge.arm.com>
-References: <1553864452-15080-1-git-send-email-Dave.Martin@arm.com>
- <1553864452-15080-14-git-send-email-Dave.Martin@arm.com>
- <20190403200145.c2oep2hbugl7db5t@kamzik.brq.redhat.com>
- <20190404081008.GY3567@e103592.cambridge.arm.com>
- <20190404083502.b7a345l2gx3df2zk@kamzik.brq.redhat.com>
- <20190404083624.GA3567@e103592.cambridge.arm.com>
- <87d0lbwj63.fsf@zen.linaroharston>
+	id 1hJeYL-00012w-1j; Thu, 25 Apr 2019 13:36:41 +0000
+Received: from mail-it1-x144.google.com ([2607:f8b0:4864:20::144])
+ by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux))
+ id 1hJeXe-0000ox-V5
+ for linux-arm-kernel@lists.infradead.org; Thu, 25 Apr 2019 13:36:07 +0000
+Received: by mail-it1-x144.google.com with SMTP id q14so139947itk.0
+ for <linux-arm-kernel@lists.infradead.org>;
+ Thu, 25 Apr 2019 06:35:58 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;
+ h=mime-version:references:in-reply-to:from:date:message-id:subject:to
+ :cc; bh=TBxAI38871M0LI9+CFXh2HomKpMq33+qzNpADgQoIoY=;
+ b=IHtyeunPy9wZNnadnMgYQTc4ReWRRf1GX+XvebgC4ZjzvR5szf369wqAxd4H+gMi7J
+ 1DdYjOuQBnjuropTRtzGDR24O/lkmHOrhUoAccaR56dnr6hKd37LBiE8gd1E29iviIOi
+ 4mELGFxn/TarytIpzTsifN74e3X5piHEgqbUlbVi8m0LoiHHF5LQWvj9VStRbnkC/a8W
+ Te8lYbGHXGQgigp8iDbuN++zSySMpkBRZkQ/g41/fAgpbTNT3gvlcyV2N+V/jM4pLe4R
+ kjxVHNc1/Vy2OvKtZpOz2NWvye1FGZKpqvQkh7SXCcLgrzz+MsoEFcAzSIh52PVzsSh4
+ paBw==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:references:in-reply-to:from:date
+ :message-id:subject:to:cc;
+ bh=TBxAI38871M0LI9+CFXh2HomKpMq33+qzNpADgQoIoY=;
+ b=D3mOtqwHWEjTe8inYDMsc0NaKJjMnB4RdTDKkBN3wmxplOiTP9AU3b9gcf3K15IQZ+
+ ScQzBUglh5UXlnGsqUz4l5hZ8haPtrlFIF6QBApIaONWJFNJ7SfC6HxYYTX/NmnIAisM
+ h4pyS4xwjOjXUejyd0G1AQtILrDhwf3Zb/0K9a8Rcwjw3/rH4pv7+pfFvqkjg43u7gH2
+ 8ew+y4nza4cm9UokP9pjfjT7XcBmcKK4DwA9BxsiTzb8Z50/r6iBfFRuRtb8L/o/8NYk
+ AB6Z3PmNjeYDk3zyEpyyVq2aGFdUCiCc+7dtzR2z2whY9xkndNswdkcKs63kPl6KbP1L
+ 7g1w==
+X-Gm-Message-State: APjAAAWplYSqtlhuDBHEqxBIVu8uAoddLhsZlvlB/d3WlTahu4KLe3N8
+ 0rXBSSC8CSTmxEneP4c4ZVhaT4YCw4G9gUpssLzzvA==
+X-Google-Smtp-Source: APXvYqwgu+RJDv37GWOQ4yFuEFEWXD+us9+T0OQiTTMY0DcZ6GwvdELkmmk1jToUPwAKAKtubqPBy7fMpEjDyneD/b8=
+X-Received: by 2002:a05:660c:4c2:: with SMTP id
+ v2mr3985587itk.71.1556199357742; 
+ Thu, 25 Apr 2019 06:35:57 -0700 (PDT)
 MIME-Version: 1.0
-Content-Disposition: inline
-In-Reply-To: <87d0lbwj63.fsf@zen.linaroharston>
-User-Agent: Mutt/1.5.23 (2014-03-12)
+References: <20190425102020.21533-1-ard.biesheuvel@linaro.org>
+ <20190425102020.21533-4-ard.biesheuvel@linaro.org>
+ <CACRpkdacwYder5e0ik2T32heSBQhKvmbem8XMpUF0iShsw3D3w@mail.gmail.com>
+In-Reply-To: <CACRpkdacwYder5e0ik2T32heSBQhKvmbem8XMpUF0iShsw3D3w@mail.gmail.com>
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Thu, 25 Apr 2019 15:35:45 +0200
+Message-ID: <CAKv+Gu9+NqrtOrdkxcwPz63EW9gGnHLADTR9K2EPRsm0nHOS4g@mail.gmail.com>
+Subject: Re: [RFC PATCH 3/3] gpio: mb86s70: enable ACPI and irqchip support
+To: Linus Walleij <linus.walleij@linaro.org>
 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
-X-CRM114-CacheID: sfid-20190425_063511_856598_1EF9E63E 
-X-CRM114-Status: GOOD (  34.51  )
+X-CRM114-CacheID: sfid-20190425_063559_940694_7B9D55FD 
+X-CRM114-Status: GOOD (  23.54  )
 X-BeenThere: linux-arm-kernel@lists.infradead.org
 X-Mailman-Version: 2.1.21
 Precedence: list
@@ -76,149 +91,110 @@
 List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
 List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>, 
  <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe>
-Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com>,
- Christoffer Dall <cdall@kernel.org>,
- Ard Biesheuvel <ard.biesheuvel@linaro.org>,
- Marc Zyngier <marc.zyngier@arm.com>, Catalin Marinas <catalin.marinas@arm.com>,
- Will Deacon <will.deacon@arm.com>, Zhang Lei <zhang.lei@jp.fujitsu.com>,
- Julien Grall <julien.grall@arm.com>, kvmarm@lists.cs.columbia.edu,
- linux-arm-kernel@lists.infradead.org
-Content-Type: text/plain; charset="iso-8859-1"
-Content-Transfer-Encoding: quoted-printable
+Cc: Graeme Gregory <graeme.gregory@linaro.org>,
+ Marc Zyngier <marc.zyngier@arm.com>,
+ "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
+ Masahisa Kojima <masahisa.kojima@linaro.org>,
+ Mika Westerberg <mika.westerberg@linux.intel.com>,
+ Linux ARM <linux-arm-kernel@lists.infradead.org>
+Content-Type: text/plain; charset="us-ascii"
+Content-Transfer-Encoding: 7bit
 Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org>
 Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org
 
-On Wed, Apr 24, 2019 at 03:51:32PM +0100, Alex Benn=E9e wrote:
-> =
-
-> Dave Martin <Dave.Martin@arm.com> writes:
-> =
-
-> > On Thu, Apr 04, 2019 at 10:35:02AM +0200, Andrew Jones wrote:
-> >> On Thu, Apr 04, 2019 at 09:10:08AM +0100, Dave Martin wrote:
-> >> > On Wed, Apr 03, 2019 at 10:01:45PM +0200, Andrew Jones wrote:
-> >> > > On Fri, Mar 29, 2019 at 01:00:38PM +0000, Dave Martin wrote:
-> >> > > > In order to give each vcpu its own view of the SVE registers, th=
-is
-> >> > > > patch adds context storage via a new sve_state pointer in struct
-> >> > > > vcpu_arch.  An additional member sve_max_vl is also added for ea=
-ch
-> >> > > > vcpu, to determine the maximum vector length visible to the guest
-> >> > > > and thus the value to be configured in ZCR_EL2.LEN while the vcpu
-> >> > > > is active.  This also determines the layout and size of the stor=
-age
-> >> > > > in sve_state, which is read and written by the same backend
-> >> > > > functions that are used for context-switching the SVE state for
-> >> > > > host tasks.
-> >> > > >
-> >> > > > On SVE-enabled vcpus, SVE access traps are now handled by switch=
-ing
-> >> > > > in the vcpu's SVE context and disabling the trap before returning
-> >> > > > to the guest.  On other vcpus, the trap is not handled and an ex=
-it
-> >> > > > back to the host occurs, where the handle_sve() fallback path
-> >> > > > reflects an undefined instruction exception back to the guest,
-> >> > > > consistently with the behaviour of non-SVE-capable hardware (as =
-was
-> >> > > > done unconditionally prior to this patch).
-> >> > > >
-> >> > > > No SVE handling is added on non-VHE-only paths, since VHE is an
-> >> > > > architectural and Kconfig prerequisite of SVE.
-> >> > > >
-> >> > > > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
-> >> > > > Reviewed-by: Julien Thierry <julien.thierry@arm.com>
-> >> > > > Tested-by: zhang.lei <zhang.lei@jp.fujitsu.com>
-> >> > > >
-> >> > > > ---
-> >> > > >
-> >> > > > Changes since v5:
-> >> > > >
-> >> > > >  * [Julien Thierry, Julien Grall] Commit message typo fixes
-> >> > > >
-> >> > > >  * [Mark Rutland] Rename trap_class to hsr_ec, for consistency w=
-ith
-> >> > > >    existing code.
-> >> > > >
-> >> > > >  * [Mark Rutland] Simplify condition for refusing to handle an
-> >> > > >    FPSIMD/SVE trap, using multiple if () statements for clarity.=
-  The
-> >> > > >    previous condition was a bit tortuous, and how that the stati=
-c_key
-> >> > > >    checks have been hoisted out, it makes little difference to t=
-he
-> >> > > >    compiler how we express the condition here.
-> >> > > > ---
-> >> > > >  arch/arm64/include/asm/kvm_host.h |  6 ++++
-> >> > > >  arch/arm64/kvm/fpsimd.c           |  5 +--
-> >> > > >  arch/arm64/kvm/hyp/switch.c       | 75 ++++++++++++++++++++++++=
-+++++----------
-> >> > > >  3 files changed, 66 insertions(+), 20 deletions(-)
-> >> > > >
-> >> > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/incl=
-ude/asm/kvm_host.h
-> >> > > > index 22cf484..4fabfd2 100644
-> >> > > > --- a/arch/arm64/include/asm/kvm_host.h
-> >> > > > +++ b/arch/arm64/include/asm/kvm_host.h
-> >> > > > @@ -228,6 +228,8 @@ struct vcpu_reset_state {
-> >> > > >
-> >> > > >  struct kvm_vcpu_arch {
-> >> > > >  	struct kvm_cpu_context ctxt;
-> >> > > > +	void *sve_state;
-> >> > > > +	unsigned int sve_max_vl;
-> >> > > >
-> >> > > >  	/* HYP configuration */
-> >> > > >  	u64 hcr_el2;
-> >> > > > @@ -323,6 +325,10 @@ struct kvm_vcpu_arch {
-> >> > > >  	bool sysregs_loaded_on_cpu;
-> >> > > >  };
-> >> > > >
-> >> > > > +/* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
-> >> > > > +#define vcpu_sve_pffr(vcpu) ((void *)((char *)((vcpu)->arch.sve=
-_state) + \
-> >> > > > +				      sve_ffr_offset((vcpu)->arch.sve_max_vl)))
-> >> > >
-> >> > > Maybe an inline function instead?
-> >> >
-> >> > I tried, but that requires the definition of struct kvm_vcpu to be
-> >> > visible.  I failed to get that here without circular #include proble=
-ms,
-> >> > and it looked tricky to fix.
-> >>
-> >> Ah, OK
-> >>
-> >> >
-> >> > Since this is a small bit of code which is unlikely to get used by
-> >> > accident, I decided it was OK to keep it as a macro.
-> >> >
-> >> > Can you see another way around this?
-> >>
-> >> Nope
+On Thu, 25 Apr 2019 at 15:24, Linus Walleij <linus.walleij@linaro.org> wrote:
+>
+> Hi Ard, thanks for your patch!
+>
+> Including Mika here as well, he knows how ACPI is supposed to
+> be wired up with GPIOs.
+>
+> On Thu, Apr 25, 2019 at 12:20 PM Ard Biesheuvel
+> <ard.biesheuvel@linaro.org> wrote:
+>
+> > In order to support this GPIO block in combination with an EXIU
+> > interrupt controller on ACPI systems such as Socionext SynQuacer,
+> > add the enumeration boilerplate, and add the EXIU irqchip handling
+> > to the probe path. Also, make the clock handling conditonal on
+> > non-ACPI enumeration, since ACPI handles this internally.
 > >
-> > OK.  If someone eventually solves this, I'd be happy to change to an
-> > inline function.
-> =
+> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+> (...)
+>
+> > +config GPIO_MB86S7X_ACPI
+> > +       def_bool y
+> > +       depends on ACPI && ARCH_SYNQUACER
+>
+> I would say
+>
+> depends on ACPI
+> depends on (ARCH_SYNQUACER || COMPILE_TEST)
+>
+> so we get some compiler coverage.
+>
+> > +#include <linux/acpi.h>
+> >  #include <linux/io.h>
+> >  #include <linux/init.h>
+> >  #include <linux/clk.h>
+> > @@ -27,6 +28,8 @@
+> >  #include <linux/spinlock.h>
+> >  #include <linux/slab.h>
+> >
+> > +#include "gpiolib.h"
+>
+> Normally not a good sign to dereference gpiolib internals,
+> but there are some few exceptions. Why do you do this?
+>
 
-> Is the function intended to be used by more call sites? Currently in the
-> tree with this plus the v2 fixups I can only see:
-> =
+I needed this for acpi_gpiochip_request_interrupts() et al
 
->   arch/arm64/include/asm/kvm_host.h:333:#define vcpu_sve_pffr(vcpu) ((voi=
-d *)((char *)((vcpu)->arch.sve_state) + \
->   arch/arm64/kvm/hyp/switch.c:388:		sve_load_state(vcpu_sve_pffr(vcpu),
+> > +int exiu_acpi_init(struct platform_device *pdev, struct gpio_chip *gc);
+>
+> Just merge it all into one file instead of having these crisscrossy calls.
+> I prefer some minor #ifdef or straight C if (IS_ENABLED()) around
+> specific code.
+>
 
-Probably not, although it was probably used to save the state back
-before things were refactored so that fpsimd_save() in
-arch/arm64/kernel/fpsimd.c is used instead of separate code to save the
-vcpu state.
+Fair enough, but please see below.
 
-The expression is ugly so it's nice to abstract it.  This also keeps
-the sve_load_state() call feeling consistent to the equivalent call in
-task_fpsimd_load() in arm64/kernel/fpsimd.c
+> > -       return ret;
+> > +       if (mb86s70_gpio_have_acpi(pdev))
+> > +               acpi_gpiochip_request_interrupts(&gchip->gc);
+> > +
+> > +       return 0;
+>
+> I guess this is right...
+>
+> >         struct mb86s70_gpio_chip *gchip = platform_get_drvdata(pdev);
+> >
+> > +       if (gchip->gc.irq.domain) {
+> > +               acpi_gpiochip_free_interrupts(&gchip->gc);
+> > +               irq_domain_remove(gchip->gc.irq.domain);
+> > +       }
+>
+> Mika can possibly comment on the right way to do ACPI bring-up
+> and take-down.
+>
+> Overall it looks pretty straightforward to me, but I'd prefer to just
+> merge the irqchip driver over into the gpio driver, I can't see why
+> not.
+>
+> Or is the irqchip used without the GPIO driver sometimes?
+>
 
-Other than that, there's no underlying reason for having a macro.
+This is where it becomes a bit nasty: the GPIO controller and the EXIU
+interrupt controller are two separate IP blocks, but they are
+obviously complimentary. *However*, on SynQuacer, the first 4 physical
+lines are not shared between the two, and so you could have 4
+interrupt lines handled through the EXIU and 4 different GPIO lines
+through the GPIO unit.
 
-Cheers
----Dave
+On DT, we don't care since we model them as two different units. On
+ACPI, however, we cannot model interrupt controllers in the same way,
+and so I decided to merge them.
+
+Perhaps the solution is to model the EXIU as a pseudo-GPIO block that
+only supports interrupts and not ordinary GPIO?
 
 _______________________________________________
 linux-arm-kernel mailing list