diff options
| author | Masami Hiramatsu <masami.hiramatsu@linaro.org> | 2022-02-16 15:15:42 +0900 |
|---|---|---|
| committer | Heinrich Schuchardt <heinrich.schuchardt@canonical.com> | 2022-02-26 07:37:00 +0100 |
| commit | a6aafce494ab3d963485e6425f232a9224359556 (patch) | |
| tree | 3112466395b2a39f706866029d9fb4e33ddf28d1 | |
| parent | bdcc0a9594d4d3ae02f9f013e105e9a7430b3266 (diff) | |
| download | u-boot-a6aafce494ab3d963485e6425f232a9224359556.zip u-boot-a6aafce494ab3d963485e6425f232a9224359556.tar.gz u-boot-a6aafce494ab3d963485e6425f232a9224359556.tar.bz2 | |
efi_loader: use efi_update_capsule_firmware() for capsule on disk
Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.
Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().
This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.
Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
| -rw-r--r-- | lib/efi_loader/efi_capsule.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index f4519c7..d814117 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -1118,7 +1118,7 @@ efi_status_t efi_launch_capsules(void) index = 0; ret = efi_capsule_read_file(files[i], &capsule); if (ret == EFI_SUCCESS) { - ret = EFI_CALL(efi_update_capsule(&capsule, 1, 0)); + ret = efi_capsule_update_firmware(capsule); if (ret != EFI_SUCCESS) log_err("Applying capsule %ls failed\n", files[i]); |