On Tue, Jul 25, 2017 at 10:28 AM, Alexander Graf <ag...@suse.de> wrote: > > > On 25.07.17 14:28, Rob Clark wrote: >> >> On Tue, Jul 25, 2017 at 8:16 AM, Alexander Graf <ag...@suse.de> wrote: >> >>> I personally think having _ext functions in anything exposed to UEFI >>> payloads makes more sense. >>> >> >> having 2x all the interfaces for file related protocols would be > > > Why 2x the interfaces?
well, maybe not all, but for efi_load_image() from a device-path to work, we need to be able to use simple-filesystem-protocol and a bunch of the file-protocol interfaces.. so it is definitely more messy. >> unfortunate. (Also currently they can stay static in efi_file.c and >> just be called via same efi_file_handle fxn ptrs that the UEFI world >> would be using, which is kinda nice.) > > > Ah, that indeed is nice. > > So, there is a third option if you want to tackle it: > > 3) Remove register variable need for gd > > If gd is a simple global variable rather than a register variable, we > wouldn't have that problem. On x86 it's just a variable for example. I don't > know why arm and aarch64 have it as register variable, but I can't see an > immediate need for it. > > If you manage to solve that, we don't need any ext functions or reference > counters ;). It would be nice to not have this gd mess.. although I'm going to leave it to someone else who understands better why we do that in the first place to solve. I have a big pile of display-handover (clk/powerdomain/display-controller-state) issues on my TODO list, and I'm just trying to get the bootloader sorted to the point where I can tackle that. Not to mention a big pile of things todo in mesa, and my actual $day_job. I think with the EFI interfaces I need to use for efi_load_image, it should be easy enough to keep any of those from calling back into the UEFI world, and we could do some sort of EFI_CALLBACK() macro with some extra error checking to safeguard instead of the EFI_EXIT()+callback+EFI_ENTER() pattern.. and while it is a bit annoying to have to be careful about that, I think it would work ok if no one has a solution for the gd mess in sight. BR, -R _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
