[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEEQ3wkT_2GbdsjfA_VA+LeyCzdeQ+Bh+admyVjz7rE3cSWSxA@mail.gmail.com>
Date: Mon, 26 Jun 2023 18:19:44 +0800
From: 运辉崔 <cuiyunhui@...edance.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: ron minnich <rminnich@...il.com>,
Mark Rutland <mark.rutland@....com>,
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,
lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-acpi@...r.kernel.org,
葛士建 <geshijian@...edance.com>,
韦东 <weidong.wd@...edance.com>
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
passing method FFI
Hi Ard, Mark,
On Mon, Jun 26, 2023 at 4:23 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> DT support for SMBIOS can live in generic code, but the binding has to
> be sane. As I suggested before, it probably makes sense to supplant
> the entrypoint rather than just carry its address - this means a 'reg'
> property with base and size to describe the physical region, and at
> least major/minor/docrev fields to describe the version.
Regarding dts node binding, our current definition is as follows:
/dts
{
...
cfgtables {
acpi_phy_ptr = 0000000000000000; //u64
smbios_phy_ptr = 0000000000000000; //u64
...
}
...
}
x86 only gave a root_pointer entry address
u64 x86_default_get_root_pointer(void)
{
return boot_params.acpi_rsdp_addr;
}
Regarding the naming of the binding above, Mark, do you have any suggestions?
> For the ACPI side, you should just implement
> acpi_arch_get_root_pointer() under arch/riscv, and wire it up in
> whichever way you want. But please check with the RISC-V maintainers
> if they are up for this, and whether they want to see this mechanism
> contributed to one of the pertinent specifications.
You suggest putting SMBIOS in general code instead of ACPI, why?
>From the perspective of firmware information passing, they are a class.
SMBIOS and ACPI are not related to ARCH, nor is DTS to obtain firmware
information,
Why do you have to put part of the ACPI code under arch/risc-v/?
The scope of the previous discussion was limited to RISC-V because of
historical reasons such as the binding with EFI on ARM64. We will only
enable this function on RISC-V in subsequent patches.
The realization of the FFI scheme itself is irrelevant to the arch.
Thanks,
Yunhui
Powered by blists - more mailing lists