[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160614164116.GF16531@arm.com>
Date: Tue, 14 Jun 2016 17:41:16 +0100
From: Will Deacon <will.deacon@....com>
To: Aleksey Makarov <aleksey.makarov@...aro.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Graeme Gregory <graeme.gregory@...aro.org>,
Jon Masters <jcm@...hat.com>, "Zheng, Lv" <lv.zheng@...el.com>,
Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH v3 5/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE
On Tue, Jun 14, 2016 at 06:51:19PM +0300, Aleksey Makarov wrote:
>
> On 06/02/2016 08:49 PM, Aleksey Makarov wrote:
> > From: Jon Masters <jcm@...hat.com>
> >
> > This patch adds support for ACPI_TABLE_UPGRADE for ARM64
>
> Hi Catalin, Will,
>
> Can you review this v3 patch please? I changed PFN_PHYS(max_pfn) to
> MEMBLOCK_ALLOC_ACCESSIBLE.
I'm inclined to agree with Mark that this is something that should be
done by the bootloader (e.g. GRUB) if it's needed, rather than something
we should support in the kernel. Jon pitched the feature as a developer
aid for triaging problems, so it's not like we're in a state where some
widely available machine cannot currently boot Linux without this.
Having said that, the patch isn't exactly invasive and I suspect it's
only a matter of time before we will actually want something like this.
So I've come full circle on this patch:
Acked-by: Will Deacon <will.deacon@....com>
Will
Powered by blists - more mailing lists