[PATCH 00/13] efi: Tidy up confusion between pointers and addresses

[Simon Glass]

Hi Tom,

On Tue, 26 Nov 2024 at 09:08, Tom Rini <trini at konsulko.com> wrote:
>
> On Tue, Nov 26, 2024 at 08:39:05AM -0700, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 26 Nov 2024 at 02:10, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > >
> > > On 25.11.24 21:44, Simon Glass wrote:
> > > > The EFI-loader implementation converts things back and forth between
> > > > addresses and pointers, with not much consistency in how this is done.
> > > >
> > > > Within most of U-Boot a pointer is a void * and an address is a ulong
> > >
> > > No. It is phys_addr_t that was introduced to handle the sandbox's
> > > virtual addresses.
> > >
> > > And we should keep this sandbox stuff out of the EFI code. They are only
> > > needed for the command line interface.
> >
> > No. My statement is correct and long predates sandbox. U-Boot has
> > always used ulong. Using an address is generally much easier than a
> > pointer, so I believe this design decision was (and remains) a good
> > one. I certainly would not support changing it. The phys_addr_t type
> > has nothing to do with sandbox.
>
> At the high level, I think parts of the problem are that when U-Boot
> went from 32bit architectures to 36bit architectures (assorted PowerPC
> Freescale parts) to 64bit architectures that no, we didn't make some
> concious and consistent statement that "ulong is for address (except
> when it's not). If you look at the linux kernel, phys_addr_t is physical
> addresses, ulong is virtual addresses.
>
> And so phys_addr_t was introduced, iirc, for PowerPC where we had a
> 32bit architecture with 36bit addresses and had to deal with that.

OK, thanks.

I'm a bit unsure what to do here...but am leaning towards having a
separate struct for the memory areas in struct efi_mem_list, rather
than using the same efi_mem_desc. Then I can have one use addresses
and the other pointers.

Regards,
Simon