Message-ID: <ZEpbTE4gcsf8meXc@FVFF77S0Q05N>
Date:   Thu, 27 Apr 2023 12:24:15 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     ron minnich <rminnich@...il.com>
Cc:     运辉崔 <cuiyunhui@...edance.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>, rafael@...nel.org,
        lenb@...nel.org, jdelvare@...e.com, yc.hung@...iatek.com,
        angelogioacchino.delregno@...labora.com,
        allen-kh.cheng@...iatek.com, pierre-louis.bossart@...ux.intel.com,
        tinghan.shen@...iatek.com, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
 passing method FFI

On Wed, Apr 26, 2023 at 09:04:56PM -0700, ron minnich wrote:
> The device tree is self describing data. Adding new information is easy. If you
> add new information to a node, and older software does not know about it, it is
> no big deal.

It's true that it's easy to add fields to an extensible format, but that wasn't
my point of contention. The *semantic* (e.g. all of the relevant DT bindings)
and *consumption* of that data is the important part, and that's what I was
referring to, though I appreciate my wording did not make that clear.

> So I can't agree with this comment: "We'd have to create entirely new ways to
> pass that information, which is not
> very desirable."
> 
> The whole point of the dt is that you can always add new ways to pass
> information, by design. 
> 
> Adding memory attributes would be quite easy.

I don't disagree that is physically possible, and in isolation adding
properties to a DT is trivial, but the approach proposed is not "easy" unless
you ignore the cost of specifying analogues for all the EFI portions that you
plan to omit, ensuring that those stay functionally equivalent to their EFI
analogues as EFI and ACPI evolve over time, developing and maintaining the code
which must consume that, avoiding the issues that will arise due to novel
interactions (as e.g. DT and ACPI are mutually exclusive today, by design),
etc.

For example, the UEFI memory map is semantically and structurally different
from DT memory nodes. It encodes *different* information, and in practice needs
to encode a larger number of physical extents with properties (e.g.
cacheability, permissions) associated with each extent. The existing DT memory
nodes format isn't really amenable to encoding this, inventing a parallel
structure for this opens up all the usual problems of the two becoming
out-of-sync, and inventing a new mechanism to describe all of this in a
consistent way duplicates all the work done for EFI.

I appreciate that at a high level of abstractions this seems conceptually
simple, but in practice this is a complex area where components have subtle and
often implicit dependencies, and so there is inherent fractal complexity.

Thanks,
Mark.

> On Wed, Apr 26, 2023 at 8:38 PM 运辉崔 <cuiyunhui@...edance.com> wrote:
> 
>     Hi Mark,
> 
>     On Wed, Apr 26, 2023 at 6:07 PM Mark Rutland <mark.rutland@....com> wrote:
>     >
>     > Ard's point is that the device tree doesn't have all the same information
>     (e.g.
>     > nothing in DT describes the memory type attributes), and so this isn't
>     > sufficient.
> 
>     The device tree only needs to complete the parse of the memory type
>     attributes,
>     it should not be very complicated.
> 
>     >
>     > We'd have to create entirely new ways to pass that information, which is
>     not
>     > very desirable.
>     >
> 
>     >
>     > Can you extend coreboot to provide EFI services, or to chain-load an EFI
>     > payload?
> 
>     Currently, coreboot does not support UEFI, and it may not support it
>     in the future.
>     Hi rminnich, what do you think?
> 
>     Thanks,
>     Yunhui
> 

Powered by blists - more mailing lists