Re: [PATCH] x86, efi: Fix a build warning

From: Matt Fleming
Date: Wed Apr 24 2013 - 07:18:10 EST


On 24/04/13 11:56, Ingo Molnar wrote:
>
> * Borislav Petkov <bp@xxxxxxxxx> wrote:
>
>> From: Borislav Petkov <bp@xxxxxxx>
>>
>> Fix this:
>>
>> arch/x86/boot/compressed/eboot.c: In function ???setup_efi_vars???:
>> arch/x86/boot/compressed/eboot.c:269:2: warning: passing argument 1 of ???efi_call_phys??? makes pointer from integer without a cast [enabled by default]
>> In file included from arch/x86/boot/compressed/eboot.c:12:0:
>> /w/kernel/linux/arch/x86/include/asm/efi.h:8:33: note: expected ???void *??? but argument is of type ???long unsigned int???
>>
>> after cc5a080c5d40 ("efi: Pass boot services variable info to runtime
>> code").
>>
>> Cc: Matthew Garrett <matthew.garrett@xxxxxxxxxx>
>> Cc: Matt Fleming <matt.fleming@xxxxxxxxx>
>> Signed-off-by: Borislav Petkov <bp@xxxxxxx>
>> ---
>> arch/x86/boot/compressed/eboot.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
>> index 8615f7581820..41de115a55b7 100644
>> --- a/arch/x86/boot/compressed/eboot.c
>> +++ b/arch/x86/boot/compressed/eboot.c
>> @@ -266,7 +266,7 @@ static efi_status_t setup_efi_vars(struct boot_params *params)
>> while (data && data->next)
>> data = (struct setup_data *)(unsigned long)data->next;
>>
>> - status = efi_call_phys4(sys_table->runtime->query_variable_info,
>> + status = efi_call_phys4((void *)sys_table->runtime->query_variable_info,
>> EFI_VARIABLE_NON_VOLATILE |
>> EFI_VARIABLE_BOOTSERVICE_ACCESS |
>> EFI_VARIABLE_RUNTIME_ACCESS, &store_size,
>
> Why isn't the query_variale_info field changed to void * instead? That way
> no cast would be needed.

We could either change all fields in efi_system_table or the
efi_call_phys* prototypes. x86-64 already casts to (void *) when calling
efi_call0(), etc, though I'm not entirely sure why void * is needed.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/