lkml.org 
[lkml]   [2017]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types
    On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote:
    > Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a
    > hardcoded 0.
    >
    > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    > ---
    > arch/x86/platform/efi/efi.c | 4 ++--
    > 1 file changed, 2 insertions(+), 2 deletions(-)
    >
    > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
    > index a15cf81..6407103 100644
    > --- a/arch/x86/platform/efi/efi.c
    > +++ b/arch/x86/platform/efi/efi.c
    > @@ -1037,7 +1037,7 @@ u32 efi_mem_type(unsigned long phys_addr)
    > efi_memory_desc_t *md;
    >
    > if (!efi_enabled(EFI_MEMMAP))
    > - return 0;
    > + return EFI_RESERVED_TYPE;
    >
    > for_each_efi_memory_desc(md) {
    > if ((md->phys_addr <= phys_addr) &&
    > @@ -1045,7 +1045,7 @@ u32 efi_mem_type(unsigned long phys_addr)
    > (md->num_pages << EFI_PAGE_SHIFT))))
    > return md->type;
    > }
    > - return 0;
    > + return EFI_RESERVED_TYPE;
    > }

    I see what you're getting at here, but arguably the return value in
    these cases never should have been zero to begin with (your change
    just makes that more obvious).

    Returning EFI_RESERVED_TYPE implies an EFI memmap entry exists for
    this address, which is misleading because it doesn't in the hunks
    you've modified above.

    Instead, could you look at returning a negative error value in the
    usual way we do in the Linux kernel, and update the function prototype
    to match? I don't think any callers actually require the return type
    to be u32.

    \
     
     \ /
      Last update: 2017-02-21 13:05    [W:4.084 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site