[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhSdy1uOVg6R24Wx-g0Z-ejunMfbE9R7yhu8fEGfLzmqE1Bhg@mail.gmail.com>
Date: Sat, 19 Jan 2019 16:12:22 +0530
From: Anup Patel <anup@...infault.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Palmer Dabbelt <palmer@...ive.com>,
Albert Ou <aou@...s.berkeley.edu>,
Anup Patel <anup.patel@....com>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
Atish Patra <atish.patra@....com>,
Paul Walmsley <paul.walmsley@...ive.com>,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 2/5] RISC-V: Setup init_mm before parse_early_param()
On Tue, Jan 15, 2019 at 7:14 PM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Mon, Jan 07, 2019 at 09:40:44PM +0530, Anup Patel wrote:
> > From: Anup Patel <anup.patel@....com>
> >
> > We should setup init_mm before doing parse_early_param()
> > in setup_arch() to be consistent with setup_arch() of
> > other architectures such as x86, ARM, and ARM64.
> >
> > Signed-off-by: Anup Patel <anup.patel@....com>
>
> Is there any good inherent reason why the order matters? Not that I
> really care either way..
The parse_early_param() calls param callbacks in variety
of subsystems including MM. Doing init_mm setup before
parse_early_param() ensures that initial MM state is
available when MM param callbacks are called.
My intention was mainly to make boot-up flow similar
to x86, ARM and ARM64 so that it is easy to add
features already present in these arch ports.
Regards,
Anup
Powered by blists - more mailing lists