RFC efi: MMC proxy support for the UEFI varstore
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/3] efi: MMC proxy support for the UEFI varstore
Quoted 19 lines · Ard Biesheuvel
================================================================================
NOTE: this is a work in progress, and not fully functional yet. In particular, the actual MMC host protocol methods are stubbed out at the moment, and need to be wired up to the Linux device drivers.
================================================================================On mobile and embedded systems, there is usually only a single MMC device for non-volatile storage, which sits behind a controller that is owned by the OS at runtime. This makes it difficult to host the UEFI variable store on MMC as well, since the UEFI runtime services routines expect ownership of the underlying device as well.
This series proposes an approach to work around this. It implements the UEFI MMC host protocol in the kernel, in a way that makes it possible to expose it to the firmware. At the same time, the firmware needs be set up for this, i.e., it needs to expose its MMC host protocol pointer via a UEFI configuration table, so that the kernel can override it if it decides to expose this functionality to the firmware.
Quoted 3 lines
Note that these patches are based on patches in the EFI tree that are queued for v4.9, which replace the runtime wrappers spinlock with a semaphore. This allows us to sleep in the firmware callbacks.
Would it be possible to implement the UEFI varstore more generally on top of the Linux pstore interface and then have a pstore backend on top of MMC? That could give us very similar behavior, but also a bit more flexibility. It would be a bit confusing to have the 'dmesg' pstore target on top of UEFI varstore which in turn is on top of pstore on MMC, but I think that's ok as long as we prevent recursion.
Arnd