On Mon, 26 Jun 2023 at 10:05, 运辉崔 <cuiyunhui@xxxxxxxxxxxxx> wrote: > > Hi Ard, > > On Mon, Jun 26, 2023 at 2:43 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > I think all of this belongs under arch/riscv > > Could you look at the content of the patch again? As we discussed > before, we need to connect to the ACPI and the SMBIOS entry > At least this part of the code has to be placed in the corresponding place: > drivers/acpi/osl.c: acpi_os_get_root_pointer() > drivers/firmware/dmi_scan.c:dmi_scan_machine() > > Because obtaining firmware information through DTS belongs to the > content of the driver firmware, it is appropriate to put this piece of > code in drivers/firmware/ffi.c. > > So I insist on the current revision, what do you think? > 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. In any case, there is really no point in supporting both entrypoints (this applies to the ACPI root pointer as well). 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. So NAK on the current revision, in case this was unclear.
