From: Simon Glass sjg@chromium.org Date: Wed, 27 Nov 2024 06:07:05 -0700
Hi Heinrich,
On Tue, 26 Nov 2024 at 08:37, Simon Glass sjg@chromium.org wrote:
Hi Heinrich,
On Tue, 26 Nov 2024 at 02:44, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 25.11.24 21:44, Simon Glass wrote:
Rather than an integer, it is better to use the enum provided, when referring to an EFI memory-type. Update existing uses.
The C standard provides no definition of the size of the integer used to implement enums. It could use u8, u16, u32, or u64.
As EFI applications may be compiled using a different compiler we need to control the width used for passing parameters in the API interface.
We should have used u32 instead of int here. We could use a typedef for more verbosity though that is frowned upon in U-Boot.
Yes, the ext function is debatable. The rest seem OK to me, though, as they are internal functions, See also [1].
Hmm, but the spec uses enum, so arguably this patch is more correct?
Only as a way to define the constants. The actual interfaces that use the constants use UINT32, which would indeed be u32 in Linux land as Heinrich suggests.
So no, the patch isn't correct.
Best regards
Heinrich
Call the value 'mem_type' consistently. Fix up one instance of upper-case hex.
Fix up the calls in struct efi_boot_services so that they use the same enum, adding the missing parameter names and enum efi_allocate_type.
While we are here, rename the 'memory' parameter to 'memoryp' so that it is clear it is a return value.
Signed-off-by: Simon Glass sjg@chromium.org
include/efi_api.h | 6 ++++-- include/efi_loader.h | 28 ++++++++++++++------------- lib/efi_loader/efi_boottime.c | 13 +++++++------ lib/efi_loader/efi_device_path.c | 4 ++-- lib/efi_loader/efi_memory.c | 33 ++++++++++++++++---------------- 5 files changed, 45 insertions(+), 39 deletions(-)
Regards, SImon
[1] https://stackoverflow.com/questions/4879286/specifying-size-of-enum-type-in-...
Regards, Simon