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-4-mohamed.mediouni@caramail.com> <20210121112725.GA21750@willie-the-truck>
In-Reply-To: <20210121112725.GA21750@willie-the-truck>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Thu, 21 Jan 2021 12:38:44 +0100
Message-ID: <CAK8P3a0mp93afoWHnYiJ0B4uGQCG4q4W4A-O0+Cj8nCd6nL8dg@mail.gmail.com>
Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors
To:     Will Deacon <will@kernel.org>
Cc:     Mohamed Mediouni <mohamed.mediouni@caramail.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Marc Zyngier <maz@kernel.org>,
        Hector Martin <marcan@marcan.st>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Stan Skowronek <stan@corellium.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jan 21, 2021 at 12:32 PM Will Deacon <will@kernel.org> wrote:
> On Wed, Jan 20, 2021 at 02:27:13PM +0100, Mohamed Mediouni wrote:
> > Use nGnRnE instead of nGnRE on Apple SoCs to workaround a serious hardware quirk.
> >  /*
> >   * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> >   * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> > @@ -432,6 +451,13 @@ SYM_FUNC_START(__cpu_setup)
> >        * Memory region attributes
> >        */
> >       mov_q   x5, MAIR_EL1_SET
> > +#ifdef CONFIG_ARCH_APPLE
> > +     mrs     x0, MIDR_EL1
> > +     lsr     w0, w0, #24
> > +     mov_q   x1, MAIR_EL1_SET_APPLE
> > +     cmp     x0, #0x61                       // 0x61 = Implementer: Apple
> > +     csel    x5, x1, x5, eq
>
> Why does this need to be done so early? It would be a lot cleaner if we
> could detect this in a similar fashion to other errata and update the MAIR
> appropriately. If that's not possible because of early IO mappings (which
> ones?), then we could instead initialise to nGnRnE unconditionally, but
> relax it to nGnRE if we detect that we _don't_ have the erratum.

There is (at least) the custom SMP startup code that uses device
mappings. If that's the only thing that needs the modified MAIR
to be used early, I'd consider that one more reason against doing the
custom cpu_operations for now.

       Arnd