> > > > +void __init efi_memmap_free(phys_addr_t mem, unsigned int
> > > > num_entries)
> > > > +{
> > > > + unsigned long size = num_entries * efi.memmap.desc_size;
> > > > + unsigned int order = get_order(size);
> > > > + phys_addr_t end = mem + size - 1;
> > > > +
> > > > +
On 18 June 2018 at 19:20, Sai Praneeth Prakhya
wrote:
>
>> > It's a fact that memremap() and early_memremap() might never fail and
>> > this code might never get a chance to run but to maintain good kernel
>> > programming semantics, we might need this patch.
>> >
>> > Signed-off-by: Sai Praneeth
> > It's a fact that memremap() and early_memremap() might never fail and
> > this code might never get a chance to run but to maintain good kernel
> > programming semantics, we might need this patch.
> >
> > Signed-off-by: Sai Praneeth Prakhya
> > Reviewed-by: Ricardo Neri
> Please don't
Hello Sai,
On 16 June 2018 at 03:09, Sai Praneeth Prakhya
wrote:
> From: Sai Praneeth
>
> efi_memmap_alloc(), as the name suggests, allocates memory for a new efi
> memory map. It's referenced from couple of places, namely,
> efi_arch_mem_reserve() and efi_free_boot_services(). These callers,
>
From: Sai Praneeth
efi_memmap_alloc(), as the name suggests, allocates memory for a new efi
memory map. It's referenced from couple of places, namely,
efi_arch_mem_reserve() and efi_free_boot_services(). These callers,
after allocating memory, remap it for further use. As usual, a routine
check
