[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140903131818.GE3001@console-pimps.org>
Date: Wed, 3 Sep 2014 14:18:18 +0100
From: Matt Fleming <matt@...sole-pimps.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Laszlo Ersek <lersek@...hat.com>, Ingo Molnar <mingo@...nel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"x86@...nel.org" <x86@...nel.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
Matt Fleming <matt.fleming@...el.com>,
Mark Salter <msalter@...hat.com>
Subject: Re: [PATCH v2 0/5] beautify EFI memmap logs
On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> (on arm64 only)
>
> +1 for aligning between architectures
> +1 for cleaning up the output to make it more readable
Thanks Ard.
> The only thing I am not entirely convinced about is printing all those
> memory attributes: is it really so interesting to know that region X
> /can/ be configured as writeback, write through, write combining etc
> etc, as most regions seem to support most attributes, yet it tells you
> nothing about what the kernel ends up doing with that information. In
> the arm64 case, for instance, all MEMORY_WB ranges are mapped
> writeback cached, and everything else is mapped uncached.
Personally, I think it's good to get an unadulterated version of the
firmware memory map (for vicarious debugging) before the kernel has a
chance to mess with it.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists