From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Breno Leitao <leitao@debian.org>,
"sami.mujawar@arm.com" <Sami.Mujawar@arm.com>
Subject: Re: [PATCH] firmware: efi: add a separate timeout for UpdateCapsule()
Date: Thu, 3 Sep 2026 15:10:35 +0100 [thread overview]
Message-ID: <apl_29t7Jxr2mv9C@e129823.arm.com> (raw)
In-Reply-To: <960e985e-b338-4648-a29b-1f8a31e00599@app.fastmail.com>
Hi Ard,
> Hello Yeoreum Yun,
>
> On Thu, 3 Sep 2026, at 13:32, Yeoreum Yun wrote:
> > On platforms that allows to update firmware in runtime, UpdateCapsule()
> > may immediately write a firmware image to persistent storage.
> > This operation can take longer than EFI_RTS_TIMEOUT.
> >
> > Use a separate timeout for the UpdateCapsule() runtime service. By
> > default, wait indefinitely to avoid interrupting an ongoing firmware
> > update. Administrators may configure an appropriate timeout, in seconds,
> > through /sys/firmware/efi/capsule_update_timeout.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > drivers/firmware/efi/efi.c | 41 +++++++++++++++++++++++++
> > drivers/firmware/efi/runtime-wrappers.c | 14 +++------
> > include/linux/efi.h | 10 ++++++
> > 3 files changed, 55 insertions(+), 10 deletions(-)
> >
>
> Given that UpdateCapsule() is rarely used these days at runtime, I
> wonder if we should just call it synchronously instead of via the
> EFI workqueue.
>
> I assume that would also solve the timeout issue?
Might be. But it would make *non-preemptible* for UpdateCapsule().
AFAIK the purpose of running runtime service with efi_queue to
run it in indepdent context and to be preemtible in case of arm64.
Since most of UpdateCapsule() will be called via capsule-loader's misc
device, if UpdateCaspule() is called synchronously, It would be
non-preemtible in arm64 platform.
But, some platform could be preemptible while updating firmware so
I think it would be better that it would be called via EFI workqueue.
[...]
Thanks!
--
Sincerely,
Yeoreum Yun
next prev parent reply other threads:[~2026-09-03 14:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 11:32 [PATCH] firmware: efi: add a separate timeout for UpdateCapsule() Yeoreum Yun
2026-09-03 11:47 ` Ard Biesheuvel
2026-09-03 14:10 ` Yeoreum Yun [this message]
2026-09-03 14:29 ` Ard Biesheuvel
2026-09-03 14:30 ` Ard Biesheuvel
2026-09-03 14:35 ` Yeoreum Yun
2026-09-15 8:49 ` Yeoreum Yun
2026-09-17 12:47 ` Ard Biesheuvel
2026-09-17 16:01 ` Yeoreum Yun
2026-10-09 1:29 ` Yeoreum Yun
2026-10-09 11:33 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apl_29t7Jxr2mv9C@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=Sami.Mujawar@arm.com \
--cc=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=leitao@debian.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.