Re: [PATCH v4 8/8] firmware: smccc: lfa: add sysfs ABI documentation

[Andre Przywara]

Hi Sudeep,

On 9/21/26 18:19, Sudeep Holla wrote:
> On Fri, Sep 18, 2026 at 04:11:11PM +0200, Andre Przywara wrote:
> > Document the sysfs attribute files as exported by the LFA driver.
>
> Looking at the sysfs output in 2/8 message log,
> activation_pending is missing from the documentation.

Ah, good point, added now.

> > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
> > ---
> >   Documentation/ABI/testing/sysfs-firmware-lfa | 106 +++++++++++++++++++
> >   1 file changed, 106 insertions(+)
> >   create mode 100644 Documentation/ABI/testing/sysfs-firmware-lfa
> >
> > diff --git a/Documentation/ABI/testing/sysfs-firmware-lfa b/Documentation/ABI/testing/sysfs-firmware-lfa
> > new file mode 100644
> > index 0000000000000..afd349af9cf14
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-firmware-lfa
> > @@ -0,0 +1,106 @@
> > +What:		/sys/firmware/lfa
> > +Date:		May 2026
> > +Contact:	Andre Przywara <andre.przywara@xxxxxxx>
> > +Description:
> > +		The Arm Live Firmware Activation (LFA) spec describes an
> > +		interface between platform firmware (an agent) and any user
> > +		on the non-secure side (like the Linux kernel) to activate
> > +		pending firmware updates at runtime. The actual firmware
> > +		update would be provided independently (out-of-band, or
> > +		via any existing explicit firmware update mechanisms), then,
> > +		if supported, can be activated immediately, without rebooting
> > +		the system.
> > +		This directory contains one directory for each of the LFA
> > +		capable firmware images supported by the agent, identified by
> > +		its GUID. Within each directory, the same set of sysfs files
> > +		provides access to the properties and actions for this
> > +		particular firmware image.
> > +
> > +What:		/sys/firmware/lfa/<GUID>/activate
> > +Date:		May 2026
> > +Contact:	Andre Przywara <andre.przywara@xxxxxxx>
> > +Description:
> > +		(WO) Write a boolean 'true' value to trigger the
> > +		activation of that firmware component. An update must be
> > +		pending for this to be successful.
> > +
> > +What:		/sys/firmware/lfa/<GUID>/activation_capable
> > +Date:		May 2026
> > +Contact:	Andre Przywara <andre.przywara@xxxxxxx>
> > +Description:
> > +		(RO) A boolean value to show whether this firmware image is
> > +		capable of being activated.
> > +
> > +What:		/sys/firmware/lfa/<GUID>/auto_activate
> > +Date:		May 2026
> > +Contact:	Andre Przywara <andre.przywara@xxxxxxx>
> > +Description:
> > +		(RW) Write a boolean 'true' value to allow a firmware image
> > +		to be automatically activated once a new firmware update
> > +		becomes available ("pending"). This depends on a working
> > +		notification scheme, for instance via an ACPI notification
> > +		or an interrupt to notify the kernel.
> > +
> > +What:		/sys/firmware/lfa/<GUID>/cancel
> > +Date:		May 2026
> > +Contact:	Andre Przywara <andre.przywara@xxxxxxx>
> > +Description:
> > +		(WO) Write a boolean 'true' value to cancel a recently
> > +		triggered activation, if that has not finished yet.
> > +
> > +What:		/sys/firmware/lfa/<GUID>/cpu_rendezvous
> > +Date:		May 2026
> > +Contact:	Andre Przywara <andre.przywara@xxxxxxx>
> > +Description:
> > +		(RO) A boolean value to show whether this image requires
> > +		a CPU rendezvous in firmware to be activated. If true, this
> > +		means all CPUs will enter the firmware during the activation
> > +		process, so will not be able to execute kernel code or
> > +		handle interrupts for a brief moment.
>
> What use does the userspace have with this 'activation_pending' and

activation_pending is probably the most useful of those attributes, 
since it tells the user that an update image has been deployed and is 
ready to be activated. For out-of-band updates this is the only 
information that we have, if we don't allow automatic updates. Userland 
could poll this file, or rather use some udev magic to be notified, as 
Nirmoy sketched up a while ago.

> 'may_reset_cpu' ? We should drop them unless you convince otherwise.

The consequence of may_reset_cpu is that a component cannot be updated 
at the moment. I think that's an important information to have.

Besides, the idea is to rather not filter too much here, but just expose 
the information that the firmware gives us. I am expecting some userland 
component (either a daemon or fwupd) to process this information, and 
let the kernel act more or less as a middle man to do the SMC calls.

Cheers,
Andre