Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210120132717.395873-1-mohamed.mediouni@caramail.com>
 <20210120132717.395873-8-mohamed.mediouni@caramail.com> <CAK8P3a1qeVxTxZXpfMe70zpPCSBrTOz23ZTR=PHgw0PP9GUvbw@mail.gmail.com>
 <E77005CF-8B2A-4D17-9330-72ECFD7F3C93@caramail.com> <71e94b48857cbdd21c5d6bdadf148621@kernel.org>
 <2861E21B-32B9-479E-A5F6-528D021183E6@caramail.com> <7131f110736b8a17c824f39abeeaf711@kernel.org>
In-Reply-To: <7131f110736b8a17c824f39abeeaf711@kernel.org>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Thu, 21 Jan 2021 16:09:46 +0100
Message-ID: <CAK8P3a0EhemsG45RQSUQ8ON2REAbJuxcpHhMmWn+-GQCgP2t7w@mail.gmail.com>
Subject: Re: [RFC PATCH 7/7] irqchip/apple-aic: add SMP support to the Apple
 AIC driver.
To:     Marc Zyngier <maz@kernel.org>
Cc:     Mohamed Mediouni <mohamed.mediouni@caramail.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Hector Martin <marcan@marcan.st>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Will Deacon <will@kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Stan Skowronek <stan@corellium.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Jan 21, 2021 at 3:10 PM Marc Zyngier <maz@kernel.org> wrote:
> On 2021-01-21 13:34, Mohamed Mediouni wrote:
> >> On 21 Jan 2021, at 14:22, Marc Zyngier <maz@kernel.org> wrote:
> > Because UART access adapters for the new M1 Macs aren=E2=80=99t plentif=
ul
> > at all, I actually use this for development, with iPhones which have
> > much more easy to buy Lightning-to-UART adapters.
> >
> > (That=E2=80=99s why the old implementation is there too)
> >
> > Might be worth splitting the new one to a new commit though...
>
> This series is supposed to cover M1 only, and adding extra support
> as part of it is only likely to make the code harder to review.
>
> I'd rather you focus on a single IPI interface (fast or slow,
> I don't really care). Extra features can come in later.

Agreed. The slow interface is probably easier to start with,
because it avoids hooking into the FIQ, so the FIQ can be
completely decoupled from AIC and just used for the timer.

Maybe there is even a way to use more than one hardware IPI in
the AIC?

       Arnd