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

[Sudeep Holla]

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.

> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  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 at arm.com>
> +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 at arm.com>
> +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 at arm.com>
> +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 at arm.com>
> +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 at arm.com>
> +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 at arm.com>
> +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
'may_reset_cpu' ? We should drop them unless you convince otherwise.

-- 
Regards,
Sudeep