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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
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.
next prev parent reply other threads:[~2024-02-22 11:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 14:03 [PATCH] arm64: add early fixmap initialization flag skseofh
2024-02-17 14:03 ` skseofh
2024-02-19 10:48 ` Mark Rutland
2024-02-19 10:48 ` Mark Rutland
2024-02-20 0:29 ` Itaru Kitayama
2024-02-20 0:29 ` Itaru Kitayama
2024-02-20 11:55 ` Mark Rutland
2024-02-20 11:55 ` Mark Rutland
2024-02-20 23:14 ` Itaru Kitayama
2024-02-20 23:14 ` Itaru Kitayama
2024-02-22 10:59 ` Mark Rutland [this message]
2024-02-22 10:59 ` Mark Rutland
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.