[PATCH 1/6] dt-bindings: firmware: Add arm,errata-management

[Rob Herring]

On Thu, Mar 30, 2023 at 11:52 AM James Morse <james.morse at arm.com> wrote:
>
> The Errata Management SMCCC interface allows firmware to advertise whether
> the OS is affected by an erratum, or if a higher exception level has
> mitigated the issue. This allows properties of the device that are not
> discoverable by the OS to be described. e.g. some errata depend on the
> behaviour of the interconnect, which is not visible to the OS.
>
> Deployed devices may find it significantly harder to update EL3
> firmware than the device tree. Erratum workarounds typically have to
> fail safe, and assume the platform is affected putting correctness
> above performance.

Updating the DT is still harder than updating the kernel. A well
designed binding allows for errata fixes without DT changes. That
generally means specific compatibles up front rather than adding
properties to turn things on/off.

Do we really want to encourage/endorse/support non-updatable firmware?
We've rejected plenty of things with 'fix your firmware'.

> Instead of adding a device-tree entry for any CPU errata that is
> relevant (or not) to the platform, allow the device-tree to describe
> firmware's responses for the SMCCC interface. This could be used as
> the data source for the firmware interface, or be parsed by the OS if
> the firmware interface is missing.

What's to prevent vendors from only using the DT mechanism and never
supporting the SMCCC interface? I'm sure some will love to not have to
make a firmware update when they can just fix it in DT.

The downside to this extendable binding compared to simple properties
is parsing a flat tree is slow and more complicated. So it may be
difficult to support if you need this early in boot.

> Most errata can be detected from CPU id registers. These mechanisms
> are only needed for the rare cases that external knowledge is needed.

And also have significant performance impact. In the end, how many
platforms are there that can't fix these in firmware and need a
mainline/distro kernel optimized to avoid the work-around. I suspect
the number is small enough it could be a list in the kernel.

Rob