[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <561FBC99.9090501@arm.com>
Date: Thu, 15 Oct 2015 09:47:53 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: "Suzuki K. Poulose" <Suzuki.Poulose@....com>,
Mark Rutland <mark.rutland@....com>
Cc: linux-arm-kernel@...ts.infradead.org, steve.capper@...aro.org,
ard.biesheuvel@...aro.org, marc.zyngier@....com,
catalin.marinas@....com, will.deacon@....com,
linux-kernel@...r.kernel.org, christoffer.dall@...aro.org
Subject: Re: [PATCHv3 08/11] arm64: Check for selected granule support
On 10/15/2015 06:25 AM, Suzuki K. Poulose wrote:
> + /*
> + * Check to see if the CPU supports the requested pagesize
> + */
> + asm volatile("mrs %0, ID_AA64MMFR0_EL1" : "=r" (aa64mmfr0_el1));
> + aa64mmfr0_el1 >>= ID_AA64MMFR0_TGRAN_SHIFT;
> + if ((aa64mmfr0_el1 & 0xf) != ID_AA64MMFR0_TGRAN_SUPPORTED) {
> + pr_efi_err(sys_table_arg, PAGE_SIZE_STR" granule not supported by the CPU\n");
> + return EFI_UNSUPPORTED;
> + }
This is definitely an improvement over my original hack job.
I would like to add, that I actually think this should be in a new
function "check_kernel_compatibility" (or whatever) that is called
before handle_kernel_image.
That is because I don't really think it belongs in handle_kernel_image
which is focused on relocation. Plus, if you add another function, you
can avoid the "Failed to relocate kernel" error that comes out following
the granule not supported message. Further, checks like this in the
future will have a place to live.
Of course you will then need a matching stubbed out function for the
normal arm kernel as well.
Thanks,
--
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