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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: ioremap() called early from pnv_pci_init_ioda_phb()
Date:   Sat, 9 May 2020 11:37:15 -0400
Message-Id: <ABC2D7EE-2C59-4A96-A105-406F424A93AD@lca.pw>
References: <1589013450.02gfmpktnp.astroid@bobo.none>
Cc:     Christophe Leroy <christophe.leroy@c-s.fr>,
        Michael Ellerman <mpe@ellerman.id.au>,
        LKML <linux-kernel@vger.kernel.org>,
        linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
In-Reply-To: <1589013450.02gfmpktnp.astroid@bobo.none>
To:     Nicholas Piggin <npiggin@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 9, 2020, at 4:38 AM, Nicholas Piggin <npiggin@gmail.com> wrote:
>=20
> Your patch to use early_ioremap is faulting? I wonder why?

Yes, I don=E2=80=99t know the reasons either. I suppose not many places in o=
ther parts of the kernel which keep using those addresses from early_ioremap=
() after system booted. Otherwise, we would see those leak warnings elsewher=
e.

Thus, we probably have to audit the code, and if still necessary, call early=
_ioremap() and then early_iounmap() followed by a ioremap() once slab alloca=
tor is available?=