From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] of/fdt: allow FDT virtual address outside of linear direct mapping
Date: Wed, 11 Mar 2015 09:34:18 +0100 [thread overview]
Message-ID: <CAKv+Gu-76EnCfNHnqsR6SgEMO3eYi9Jn0Eg-JoNDRbBH8OFn2g@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqL=hgQWM93tgp3cCWU290-fbj37LtvqLWFo+vPFVYws3A@mail.gmail.com>
On 10 March 2015 at 22:47, Rob Herring <robh@kernel.org> wrote:
> On Tue, Mar 3, 2015 at 5:03 AM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> The early FDT code reserves the physical region that contains the
>> FDT, and uses __pa() to calculate the FDT's physical address.
>> However, if the FDT is mapped outside of the linear direct mapping,
>> __pa() cannot be used.
>>
>> So create a __weak default wrapper called fdt_virt_to_phys() around
>> __pa(), and use that instead. This allows architectures to drop in
>> their own virt/phys mapping for the FDT blob.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>
>> I am aware that __weak functions are generally frowned upon, but in this
>> case, I wonder if it is worth the trouble to add arch specific header files
>> so we can include them here.
>>
>> drivers/of/fdt.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 3a896c9aeb74..b10ce880000b 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -547,6 +547,18 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
>> }
>>
>> /**
>> + * fdt_virt_to_phys - translate a virtual address inside the FDT image
>> + * to its corresponding physical address
>> + *
>> + * This needs to be overridden by the architecture if the virtual mapping
>> + * of the FDT is separate from the linear direct mapping of system RAM
>> + */
>> +phys_addr_t __weak __init fdt_virt_to_phys(void *virt)
>> +{
>> + return __pa(virt);
>> +}
>> +
>> +/**
>> * early_init_fdt_scan_reserved_mem() - create reserved memory regions
>> *
>> * This function grabs memory from early allocator for device exclusive use
>> @@ -562,7 +574,7 @@ void __init early_init_fdt_scan_reserved_mem(void)
>> return;
>>
>> /* Reserve the dtb region */
>> - early_init_dt_reserve_memory_arch(__pa(initial_boot_params),
>> + early_init_dt_reserve_memory_arch(fdt_virt_to_phys(initial_boot_params),
>
> This is already a weak function call, so I'd rather change
> early_init_dt_reserve_memory_arch to take the virt address and do the
> conversion inside it.
> Or we could just pass both addresses from the
> arch code to the core code.
>
Alternatively, could we just have a way to tell the core FDT code
/not/ to do the reservation at all? It would make sense in the
non-linear mapped FDT case to round up the reservation to the mapped
size so that the remainder is not mapped elsewhere with different
attributes, so it is not just the physical address but also the size
that is different, and it is trivial to add the memblock_reserve() to
the remapping code.
next prev parent reply other threads:[~2015-03-11 8:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 11:03 [PATCH 0/5] arm64: update/clarify/relax Image and FDT placement rules Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 1/5] of/fdt: allow FDT virtual address outside of linear direct mapping Ard Biesheuvel
2015-03-10 21:47 ` Rob Herring
2015-03-11 8:34 ` Ard Biesheuvel [this message]
2015-03-11 11:48 ` Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 2/5] arm64: use fixmap region for permanent FDT mapping Ard Biesheuvel
2015-03-10 21:37 ` Rob Herring
2015-03-11 7:05 ` Ard Biesheuvel
2015-03-11 9:50 ` Mark Rutland
2015-03-11 10:20 ` Ard Biesheuvel
2015-03-11 10:46 ` Mark Rutland
2015-03-11 12:22 ` Rob Herring
2015-03-11 10:43 ` Mark Rutland
2015-03-11 10:54 ` Ard Biesheuvel
2015-03-11 11:56 ` Mark Rutland
2015-03-03 11:03 ` [PATCH 3/5] arm64: Documentation: clarify Image placement in physical RAM Ard Biesheuvel
2015-03-11 10:04 ` Mark Rutland
2015-03-03 11:03 ` [PATCH 4/5] arm64/efi: ensure that Image does not cross a 512 MB boundary Ard Biesheuvel
2015-03-11 11:50 ` Mark Rutland
2015-03-11 15:00 ` Ard Biesheuvel
2015-03-03 11:03 ` [PATCH 5/5] arm64/efi: adapt to relaxed FDT placement requirements Ard Biesheuvel
2015-03-11 12:09 ` Mark Rutland
2015-03-11 14:42 ` Ard Biesheuvel
2015-03-10 10:51 ` [PATCH 0/5] arm64: update/clarify/relax Image and FDT placement rules Ard Biesheuvel
2015-03-10 11:21 ` 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=CAKv+Gu-76EnCfNHnqsR6SgEMO3eYi9Jn0Eg-JoNDRbBH8OFn2g@mail.gmail.com \
--to=ard.biesheuvel@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).