linux-kernel - Re: [External] Re: [PATCH] firmware: added a firmware information passing method FFI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEEQ3wkhQJ8G-AsFBMYLFcS=rxSkPojWNLGki470WQ3XJLHoAA@mail.gmail.com>
Date:   Tue, 27 Jun 2023 15:09:10 +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,

1. Regarding the definition of DTS FFI nodes, according to your
suggestion, we plan to make the following modifications：

/ {
...
    ffi_cfg {
        acpi_tbl {
            root_pinter = ; //u64
            ...
        };
        smbios_tbl {
            root_pinter = ; //u64
            ...
        };
    };
    ...
};

2. Let's move on to the discussion: should we put code under arch/risc-v/?

On Mon, Jun 26, 2023 at 6:19 PM 运辉崔 <cuiyunhui@...edance.com> wrote:
>
> 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