Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230426034001.16-1-cuiyunhui@bytedance.com> <CAMj1kXEKh9O-ndk3QFibJMYfMbG7vm-cLN2vVQM5eDsYK84NzQ@mail.gmail.com>
 <CAEEQ3wkJB5CKm33mHXUOPX5makYOHF8By6FYGnNzRkM-Mo72OQ@mail.gmail.com>
 <ZEj33QLZqEeL+/y4@FVFF77S0Q05N> <CAEEQ3wmDBJkfOeKCQfcnuE+1=1K0D2pzu+Sn+zPEWk+RHs0NFQ@mail.gmail.com>
 <CAP6exY+ydbzh1EkWTFejzwaW+PA-ySVO2Qj+CVJ1XbSMce2S9Q@mail.gmail.com>
 <ZEpbTE4gcsf8meXc@FVFF77S0Q05N> <CAMj1kXH5kZJ6ff=PRCRDLCBcw2AkEnRL_L1ABuvu5n71=unvAw@mail.gmail.com>
 <CAEEQ3w=495snOz3UNBO4dpgyfZs3jQoRKo4QRAXXqR5-0j4SWA@mail.gmail.com>
 <CAP6exYK9ytcgqcy2gFyOGvbxd7DPGQNs=m7nNgnfunnh8et9aQ@mail.gmail.com> <CAMj1kXGB4yXCdzts2=G_-hadoka9F2BU1gvVxeLEs5ifSbqgog@mail.gmail.com>
In-Reply-To: <CAMj1kXGB4yXCdzts2=G_-hadoka9F2BU1gvVxeLEs5ifSbqgog@mail.gmail.com>
From:   =?UTF-8?B?6L+Q6L6J5bSU?= <cuiyunhui@bytedance.com>
Date:   Thu, 4 May 2023 20:05:59 +0800
Message-ID: <CAEEQ3wmcPMf44g2zRLRW3jKgd1ostpjQp=JMmwWdyYrhGQJnjA@mail.gmail.com>
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
 passing method FFI
To:     Ard Biesheuvel <ardb@kernel.org>
Cc:     ron minnich <rminnich@gmail.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Lorenzo Pieralisi <lpieralisi@kernel.org>, rafael@kernel.org,
        lenb@kernel.org, jdelvare@suse.com, yc.hung@mediatek.com,
        angelogioacchino.delregno@collabora.com,
        allen-kh.cheng@mediatek.com, pierre-louis.bossart@linux.intel.com,
        tinghan.shen@mediatek.com, linux-kernel@vger.kernel.org,
        linux-acpi@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Ron, Ard

On Sat, Apr 29, 2023 at 2:03=E2=80=AFAM Ard Biesheuvel <ardb@kernel.org> wr=
ote:
>
> On Fri, 28 Apr 2023 at 17:09, ron minnich <rminnich@gmail.com> wrote:
> >
> > There is lots of text in the preceding notes :-), which is nice because=
 we're clearly looking at something that matters!
> >
> > But, note, ARM Chromebooks run Linux, and I checked with the firmware t=
eam just now:
> > "Right. We're not using UEFI or ACPI or SMBIOS or DMI or any of that on=
 Arm. Just the Device Tree."
> >
> > So I do not agree that we need UEFI tables due to some presumed semanti=
cs that they implement, because: several tens of millions of ARM chromebook=
s running Linux show otherwise.
> >
> > We've got a chance here to move to self describing data, and I think we=
 need to take it. It will be a long time before we get this chance again.
> >

> However, introducing such a binding for SMBIOS is perfectly
> reasonable, although I would suggest that we don't copy the
> SMBIOS/SMBIOS3 entry point address into the device tree (as this patch
> does), but properly describe the memory region that contains the
> actual SMBIOS structured data directly, along with its version. This
> might be reused by other DT based platforms as well.

Could you help to give me an example to add smbios in the memmap
region description?

Even after adding to the memmap region, it needs to be connected to
the current dmi_scan_machine()?
Or add another dmi code under the fdt framework?


> Doing the same for ACPI is where we'll get into trouble, given that
> we'd end up with two conflicting hardware descriptions and unfulfilled
> dependencies on EFI specific data structures, and it is not the
> kernel's job to reason about which h/w description should take
> precedence, or to make guesses about memory types. So I fully agree
> with Ron that moving to device tree is a much better choice here -
> that way, you can avoid ACPI and UEFI altogether

Thanks for your suggestions, I don't quite get what needs to be moved
to dts? Could you explain in detail?
Is it to realize the content of acpi based on the dts framework?

Thanks,
Yunhui