All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Breno Leitao <leitao@debian.org>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	"sami.mujawar@arm.com" <Sami.Mujawar@arm.com>
Subject: Re: [PATCH] firmware: efi: add a separate timeout for UpdateCapsule()
Date: Wed, 14 Oct 2026 12:16:04 +0100	[thread overview]
Message-ID: <as9kdBzoGNEEj0Gi@e129823.arm.com> (raw)
In-Reply-To: <asjQqEKdF6YiMXxU@gmail.com>

> On Thu, Sep 17, 2026 at 05:01:20PM +0100, Yeoreum Yun wrote:
> > > > Could there be any issues with doing it this way, or would there be
> > > > a better approach?
> > > >
> > > 
> > > Would it make sense to simply have different limits for UpdateCapsule() and
> > > for everything else? How much longer than 2 minutes do you need in the
> > > typical case?
> > 
> > Although the time required to complete a firmware update depends onthe platform
> > and other factors, such as whether the capsule contains a single firmware image
> > or multiple images, it is generally reasonable to expect the update to complete
> > within 10 minutes.
> > 
> > If, for some reason, an update is expected to take longer than 10 minutes,
> > the sysfs interface for configuring capsule_update_timeout would be useful.
> > 
> > This would allow the timeout to be adjusted as needed, for example to
> > 15 minutes, before capsule update. 
> 
> In this case, if you have a worker that takes 10-15 minutes, will not 
> the workqueue stall kick in ?

Hi Breno,

Sorry for the late reply. I was on holiday.

If the default value of 30 seconds is used, it would trigger the workqueue
stall warning. However, AFAIK, wq_watchdog_thresh is configurable, and
platforms where the operation is expected to take longer than 30 seconds
should configure it accordingly.

What I want to tell is  capsule update timeout should be configurable
depending on the use case, rather than hardcoded at least.

Thanks.


-- 
Sincerely,
Yeoreum Yun

      reply	other threads:[~2026-10-14 11:16 UTC|newest]

Thread overview: 12+ 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
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
2026-10-14 11:16                   ` Yeoreum Yun [this message]

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=as9kdBzoGNEEj0Gi@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.