Re: [PATCH v3 0/8] Arm Live Firmware Activation (LFA) support

[Andre Przywara <andre.przywara@arm.com>]

Hi Michal,

thanks for having a look and for testing!

On 7/14/26 13:52, Michal Suchánek wrote:
> On Mon, Jul 13, 2026 at 06:02:35PM +0200, Michal Suchánek wrote:
>> On Mon, Jul 06, 2026 at 03:44:40PM +0200, Andre Przywara wrote:
>>> Hi all,
>>>
>>> this is version 3 of the Live Firmware Activation kernel support. The
>>> device part of the code now relies on Aneesh's SMCCC bus patches[1],
>>> which solves some problems rather nicely. I also added the formerly
>>> missing sysfs ABI documentation. Based on v7.2-rc1, plus the first
>>> two patches from Aneesh's series. More detailed changelog below.
>>> ==============================
>>>
>>> This series implements the kernel side support of the Arm Live
>>> Firmware Activation (LFA) specification [2]. LFA enables the activation
>>> of updated firmware components without requiring a system reboot,
>>> reducing downtime and allowing quicker deployment of critical bug fixes
>>> in environments such as data centers and hyperscale systems.
>>> It requires explicit firmware support, both via an agent running in EL3
>>> (for instance in TF-A, already merged), but also in the firmware
>>> component to be activated. TF-RMM recently merged support for this.
>>>
>>> Unlike the usual firmware update process (which may use tools like
>>> fwupd), LFA focuses solely on the activation of an already updated
>>> firmware component, called "pending activation" in LFA lingo. This works
>>> by signalling the LFA agent (part of the EL3 runtime firmware) via an
>>> SMC call, which then does the heavy lifting of the live update, in
>>> cooperation with the to-be-updated firmware component.
>>>
>>> Key features of the driver:
>>> * Detects LFA support in system firmware (EL3).
>>> * Lists all firmware components that support live activation, identified
>>>    by their GUID.
>>> * Exposes component attributes (e.g., activation capability, and
>>>    activation pending) via sysfs under /sys/firmware/lfa/<GUID>/.
>>> * Provides interfaces to:
>>>    - Trigger activation of an updated firmware component.
>>>    - Cancel an ongoing activation if required.
>>> A more detailed list of features can be found in patch 2/8.
>>> Based on v7.2-rc1.
>>>
>>> This work is conceptually similar to Intel’s Platform Firmware Runtime
>>> Update and telemetry (PFRUT) [3] and TDX module updates [4], but
>>> targets Arm platforms. The driver has been used to successfully activate
>>> a Realm Management Monitor (RMM) firmware image in a controlled test
>>> environment. RMM is analogous to Intel’s TDX module.
>>>
>>> There is effort on similar work from the OCP [5]. Future work may
>>> include integration with utilities like fwupd to automatically select
>>> the appropriate driver, based on platform architecture, for Live/Runtime
>>> firmware updates.
>>>
>>> Please have a look, test and comment!
>>
>> Hello,
>>
>> booting a kernel with v2 of this patchset applied the module does not
>> get autoloaded. Loading it manually I get
>>
>> [ 1972.957282] [   T5195] Arm LFA: Live Firmware Activation: detected v1.0
>> [ 1972.958620] [   T5195] Arm LFA: registered LFA ACPI notification
>>
>> Is this expected?
>>
>> I would expect the driver to load automatically.
>>
>> I do not see anything in the v3 changelog obviously addressing
>> autoloading but changing to using a bus might affect that.
>>
>> I will try to update to v3 later.
> 
> Hello,
> 
> updating to v3 of the patchset resolves the problem.

Yes, that was indeed a change that came for free with changing the 
probing method to be now SMCCC bus based. As Krzysztof rightfully 
mentioned before, the driver was always probing, then bailing out if the 
service was not available, which is not the way it should work under the 
driver model. As a side effect, there wasn't really any discovery or 
auto-loading mechanism. With the new SMCCC bus this should now all be 
solved.

Thanks for testing!
Cheers,
Andre

> The driver is now autoloaded.
> 
> Thanks
> 
> Michal