[...] > >>> + > >>> config EFI_MM_COMM_TEE > >>> bool "UEFI variables storage service via the trusted world" > >>> depends on OPTEE > >>> @@ -153,7 +171,7 @@ endchoice > >>> config EFI_RT_VOLATILE_STORE > >>> bool "Allow variable runtime services in volatile storage (e.g RAM)" > >>> - depends on EFI_VARIABLE_FILE_STORE > >>> + depends on EFI_VARIABLE_FILE_STORE || EFI_VARIABLE_SF_STORE > >> > >> Hello Michal, > >> > >> If the backend store is SPI flash, we should not publish the variable > >> "RTStorageVolatile" at runtime as currently defined. > >> > >> For the background see this commit for the efivar library: > >> > >> https://github.com/rhboot/efivar/commit/68daa04654acbe1bbaa17ebfc23c371b39e69c6b > >> > >> The first three patches look correct to me and I will add them to a merge > >> request for efi-next. > > > >Do I read it that when I don't allow to select EFI_RT_VOLATILE_STORE you > >will be fine with the patch itself? > > This was my only concern. > > Maybe setting the file name to /dev/mtd/by-name/<partition name> would work > with efivar. But I have not tested it.
I don't think it wiill. That variables describes the filename relative to the ESP > > In U-Boot we could replace EFI_VARIABLE_SF_DEVICE_INDEX, SIZE, and OFFSET by > a partition name, too. That way it would be the common device-tree for U-Boot > and Linux controlling the placement of the variables store. > > > > > > >> The usage of efi_var_mem_ins() and efi_var_mem_del() when SetVariable() > >> does not change anything is not flash-friendly. Michal, do you want to > >> have a look at this area? > > > >That's known limitation describe in EFI_VARIABLE_SF_STORE Kconfig Note. > > This could be a topic for future work. > > Best regards Cheers /Ilias > > Heinrich >
