From: Mark Rutland <mark.rutland@arm.com>
To: Itaru Kitayama <itaru.kitayama@linux.dev>
Cc: skseofh@gmail.com, catalin.marinas@arm.com, will@kernel.org,
ryan.roberts@arm.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: add early fixmap initialization flag
Date: Thu, 22 Feb 2024 10:59:51 +0000 [thread overview]
Message-ID: <ZdcpJ2zoyHJuNkSD@FVFF77S0Q05N> (raw)
In-Reply-To: <ZdUyOAQG0TK1UtTY@vm3>
On Wed, Feb 21, 2024 at 08:14:00AM +0900, Itaru Kitayama wrote:
> On Tue, Feb 20, 2024 at 11:55:30AM +0000, Mark Rutland wrote:
> > From 5f07f9c1d352f760fa7aba97f1b4f42d9cb99496 Mon Sep 17 00:00:00 2001
> > From: Mark Rutland <mark.rutland@arm.com>
> > Date: Tue, 20 Feb 2024 11:09:17 +0000
> > Subject: [PATCH] arm64: clean up fixmap initalization
> >
> > Currently we have redundant initialization of the fixmap, first in
> > early_fdt_map(), and then again in setup_arch() before we call
> > early_ioremap_init(). This redundant initialization isn't harmful, as
> > early_fixmap_init() happens to be idempotent, but it's redundant and
> > potentially confusing.
> >
> > We need to call early_fixmap_init() before we map the FDT and before we
> > call early_ioremap_init(). Ideally we'd place early_fixmap_init() and
> > early_ioremap_init() in the same caller as early_ioremap_init() is
> > somewhat coupled with the fixmap code.
> >
> > Clean this up by moving the calls to early_fixmap_init() and
> > early_ioremap_init() into a new early_mappings_init() function, and
> > calling this once in __primary_switched() before we call
> > early_fdt_map(). This means we initialize the fixmap once, and keep
> > early_fixmap_init() and early_ioremap_init() together.
> Thanks for this. Makes sense to me; would you post a proper patch
> so I can build and do a boot test, just to make sure?
I took a look, and Ard's recent changes to the boot code have removed the
duplicate call to early_fixmap_init() by other means, so we don't need to do
anything, and can forget about this patch. :)
Mark.
prev parent reply other threads:[~2024-02-22 10:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 14:03 [PATCH] arm64: add early fixmap initialization flag skseofh
2024-02-19 10:48 ` Mark Rutland
2024-02-20 0:29 ` Itaru Kitayama
2024-02-20 11:55 ` Mark Rutland
2024-02-20 23:14 ` Itaru Kitayama
2024-02-22 10:59 ` Mark Rutland [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZdcpJ2zoyHJuNkSD@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=catalin.marinas@arm.com \
--cc=itaru.kitayama@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=skseofh@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox