mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Sudeep Holla <sudeep.holla@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Salman Nabi <salman.nabi@arm.com>,
	Vedashree Vidwans <vvidwans@nvidia.com>,
	Trilok Soni <trilokkumar.soni@oss.qualcomm.com>,
	Nirmoy Das <nirmoyd@nvidia.com>,
	vsethi@nvidia.com, Varun Wadekar <vwadekar@nvidia.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v4 1/8] dt-bindings: arm: Add Live Firmware Activation
Date: Mon, 21 Sep 2026 17:41:36 +0200	[thread overview]
Message-ID: <93d25b91-a361-45af-aa2e-82118179291a@arm.com> (raw)
In-Reply-To: <20260921-nice-russet-caracal-6db6d3@sudeepholla>

Hi,

On 9/21/26 17:10, Sudeep Holla wrote:
> On Fri, Sep 18, 2026 at 04:11:04PM +0200, Andre Przywara wrote:
>> The Arm Live Firmware Activation spec [1] describes updating firmware
>> images during runtime, without requiring a reboot. Update images might
>> be deployed out-of-band, for instance via a BMC, in this case the OS
>> needs to be notified about the availability of a new image.
>>
>> Describe an interrupt that could be triggered by the platform, to notify
>> about any changes.
>>
>> [1] https://developer.arm.com/documentation/den0147/latest/
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
>> ---
>>   .../devicetree/bindings/arm/arm,lfa.yaml      | 50 +++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/arm/arm,lfa.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,lfa.yaml b/Documentation/devicetree/bindings/arm/arm,lfa.yaml
>> new file mode 100644
>> index 0000000000000..179c542f383d4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/arm,lfa.yaml
>> @@ -0,0 +1,50 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/arm,lfa.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Arm Live Firmware Activation (LFA)
>> +
>> +maintainers:
>> +  - Andre Przywara <andre.przywara@arm.com>
>> +  - Sudeep Holla <sudeep.holla@arm.com>
>> +
>> +description:
>> +  The Arm Live Firmware Activation (LFA) specification [1] describes a
>> +  firmware interface to activate an updated firmware at runtime, without
>> +  requiring a reboot. Updates might be supplied out-of-band, for instance
>> +  via a BMC, in which case the platform needs to notify an OS about pending
>> +  image updates.
>> +  [1] https://developer.arm.com/documentation/den0147/latest/
>> +
>> +properties:
>> +  compatible:
>> +    const: arm,lfa
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +    description:
>> +      The notification interrupt for changed firmware image status. For
>> +      an out-of-band firmware update, some system entity would signal
>> +      the availability of a firmware update to the host OS via this interrupt.
>> +
>> +      This must be an edge-triggered IRQ.
>> +
>> +required:
>> +  - compatible
>> +  - interrupts
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +    firmware {
>> +        firmware-update {
>> +            compatible = "arm,lfa";
>> +            interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> 
> Could the example use an edge-triggered interrupt type as it must be
> edge-triggered IRQ as per the above scheme ? As written, a device tree

Oops, sorry, of course, forgot to change that!

> copied from the example violates the binding's requirement.
> 
> Alternatively, is the binding incorrect and needs fixing ? I am not sure
> if there is any requirement on it from the specification. Where did you
> derive it from ?
Indeed the spec doesn't say that explicitly, but it's pretty mute on 
that front anyway.
The need for edge comes somewhat naturally: since the originator of the 
interrupt is unknown (the agent injecting something? Some BMC triggering 
a GPIO line? Some SPC triggering an on-chip IRQ line?), it's unclear 
whose responsibility it is the lower the IRQ line again. And even if the 
LFA agent could somehow arrange that - by having firmware component 
specific code to do that - it in unclear when exactly this lowering 
should happen: at LFA_PRIME? At LFA_ACTIVATE? Already at the first core 
calling ACTIAVTE, or only if the activation happened successfully? What 
about errors in between? What about if the admin decides to not update now?
As the spec doesn't say anything about that, and the ACPI notification 
is naturally edge, IIUC, I went with demanding an edge triggered IRQ.

Cheers,
Andre.


  reply	other threads:[~2026-09-21 15:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 14:11 [PATCH v4 0/8] Arm Live Firmware Activation (LFA) support Andre Przywara
2026-09-18 14:11 ` [PATCH v4 1/8] dt-bindings: arm: Add Live Firmware Activation Andre Przywara
2026-09-21 15:10   ` Sudeep Holla
2026-09-21 15:41     ` Andre Przywara [this message]
2026-09-18 14:11 ` [PATCH v4 2/8] firmware: smccc: Add support for Live Firmware Activation (LFA) Andre Przywara
2026-09-18 15:24   ` Mark Rutland
2026-09-21 15:25     ` Andre Przywara
2026-09-21 15:32   ` Sudeep Holla
2026-09-18 14:11 ` [PATCH v4 3/8] firmware: smccc: lfa: Add timeout and trigger watchdog Andre Przywara
2026-09-21 15:36   ` Sudeep Holla
2026-09-18 14:11 ` [PATCH v4 4/8] firmware: smccc: lfa: Register ACPI notification Andre Przywara
2026-09-21 16:04   ` Sudeep Holla
2026-09-18 14:11 ` [PATCH v4 5/8] firmware: smccc: lfa: Add auto_activate sysfs file Andre Przywara
2026-09-18 14:11 ` [PATCH v4 6/8] firmware: smccc: lfa: Register DT interrupt Andre Przywara
2026-09-21 16:09   ` Sudeep Holla
2026-09-18 14:11 ` [PATCH v4 7/8] firmware: smccc: lfa: introduce SMC access lock Andre Przywara
2026-09-18 14:11 ` [PATCH v4 8/8] firmware: smccc: lfa: add sysfs ABI documentation Andre Przywara
2026-09-21 16:19   ` Sudeep Holla

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=93d25b91-a361-45af-aa2e-82118179291a@arm.com \
    --to=andre.przywara@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nirmoyd@nvidia.com \
    --cc=robh@kernel.org \
    --cc=salman.nabi@arm.com \
    --cc=sudeep.holla@kernel.org \
    --cc=trilokkumar.soni@oss.qualcomm.com \
    --cc=vsethi@nvidia.com \
    --cc=vvidwans@nvidia.com \
    --cc=vwadekar@nvidia.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®