Pull request for UEFI sub-system for efi-2020-10-rc1

[Tom Rini]

On Sat, Jul 04, 2020 at 11:50:01AM +0200, Heinrich Schuchardt wrote:
> The following changes since commit bcfe764ee925d0820e82c69ccf75b71d142644c7:
> 
>   Merge tag 'efi-2020-07-rc6-2' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-30 17:15:39
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-10-rc1
> 
> for you to fetch changes up to 93f6201af71d9a0a521c99212e6066778270a357:
> 
>   efi_loader: imply FAT, FAT_WRITE (2020-07-03 18:03:56 +0200)
> 
> ----------------------------------------------------------------
> Pull request for UEFI sub-system for efi-2020-10-rc1
> 
> This series comprises error corrections for the UEFI subsystem:
> 
> * correct consideration of timestamps for variable authentication
> * correct collection of data regions for code authentication
> * correct unit tests to test loading dbx
> * enable FAT_WRITE as required by the UEFI spec

So, FAT_WRITE is required by the UEFI spec, ok.  Are we exposing the
ability to write files via the UEFI API?  What happens if we return
failure to write here?  I'm asking because the first thing I see
reviewing this is thee large number of platforms with:
               u-boot: add: 30/0, grow: 5/-4 bytes: 139792/-10412 (129380)
                 function                                   old     new   delta
                 tmpbuf_cluster                               -  131072 +131072

For FAT write support.  Perhaps another way of looking at it is, can we
rework the FAT write support to get that buffer dynamically?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200705/c4c7ad64/attachment.sig>