Hi Ard, > > I will defer to Mark or other DT experts to help decide on the naming > and general shape of these. Okay, thanks. > However, as I have indicated twice now, it would be better to describe > the SMBIOS structured data directly, instead of passing the physical > address of one of the existing entry points. This avoids the need for > mapping and reserving additional pages that don't carry any relevant > information. > > So the node in question should have at least (base, size) and the > major, minor and docrev version fields. Other platforms also need related memory to store this table, don't they? Coreboot also completes the construction of this table according to its existing code, rather than creating a new description method. Furthermore, As we discussed before, SMBIOS-related code should be placed in the general code, and an entry address is required to connect to dmi_scan_machine(). according to what you said (base, size, region) how can it be connected to dmi_scan with an entry address? So, For SMBIOS, only keep the smbios part in drivers/firmware/ffi.c in this patch? If yes in terms of code structure, I will update it in v2. > SMBIOS is a separate set of firmware tables that have little > significance to the kernel itself, and describing it via DT makes > sense. > > ACPI serves a similar purpose as DT, and so having both at the same > time results in a maintenance burden, where the arch code is forced to > reason about whether they are consistent with each other, and if not, > which description has precedence. > Well... I don’t want to discuss too much, according to your suggestion, To implement acpi_arch_get_root_pointer() under arch/riscv. I'll update it on v2. > If the firmware uses DT as a conduit to deliver the ACPI system > description to the OS, it is probably better to pass this via the > /chosen node as a special boot argument. > This is not the focus of our discussion this time, and we will discuss it when we discuss node naming with DTS experts. Thanks, Yunhui
