Re: [PATCH 1/2] firmware: smccc: add timeout, touch wdt

[Vedashree Vidwans]

On 2/10/26 15:10, Trilok Soni wrote:
> On 2/10/2026 2:40 PM, Vedashree Vidwans wrote:
> > Enhance PRIME/ACTIVATION functions to touch watchdog and implement
> > timeout mechanism. This update ensures that any potential hangs are
> > detected promptly and that the LFA process is allocated sufficient
> > execution time before the watchdog timer expires. These changes improve
> > overall system reliability by reducing the risk of undetected process
> > stalls and unexpected watchdog resets.
> >
> > Signed-off-by: Vedashree Vidwans <vvidwans@xxxxxxxxxx>
> > ---
> >   drivers/firmware/smccc/lfa_fw.c | 40 +++++++++++++++++++++++++++++++++
> >   1 file changed, 40 insertions(+)
> >
> > diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
> > index da6b54fe1685..b0ace6fc8dac 100644
> > --- a/drivers/firmware/smccc/lfa_fw.c
> > +++ b/drivers/firmware/smccc/lfa_fw.c
> > @@ -17,6 +17,9 @@
> >   #include <linux/array_size.h>
> >   #include <linux/list.h>
> >   #include <linux/mutex.h>
> > +#include <linux/nmi.h>
> > +#include <linux/ktime.h>
> > +#include <linux/delay.h>
> >   
> >   #undef pr_fmt
> >   #define pr_fmt(fmt) "Arm LFA: " fmt
> > @@ -37,6 +40,14 @@
> >   #define LFA_PRIME_CALL_AGAIN		BIT(0)
> >   #define LFA_ACTIVATE_CALL_AGAIN		BIT(0)
> >   
> > +/* Prime loop limits, TODO: tune after testing */
>
> Do you want to keep this TODO? Your patches are not marked as RFC.
>
> > +#define LFA_PRIME_BUDGET_US		30000000	/* 30s cap */
> > +#define LFA_PRIME_POLL_DELAY_US		10		/* 10us between polls */
>
> Are these values going to be tunable from the userspace or kernel module parameters?
>
> > +
> > +/* Activation loop limits, TODO: tune after testing */
>
> Ditto.
>
> > +#define LFA_ACTIVATE_BUDGET_US		20000000	/* 20s cap */
> > +#define LFA_ACTIVATE_POLL_DELAY_US	10		/* 10us between polls */
> ...
>
> ---Trilok Soni

Thanks for pointing this out.

The "TODO: tune after testing" comment was left in by mistake; it should 
not have been included in a non‑RFC posting.

Regarding tunability: the current series uses fixed values, but I agree 
it would be useful to make these configurable. Adding module parameter 
to adjust the timeout values would make it easier to tune them for 
different platforms and workloads.

I’ll address both of these points in the next revision of the series.

Veda