Patrick Rudolph has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/32090 )
Change subject: smbios: Add and adapt fields for version 3.2 ......................................................................
Patch Set 5:
Patch Set 5:
Patch Set 5:
Patch Set 1:
- Line 561: "_weak" so that it can be if needed for som
- Line 829: I agree that the entry point should be added as as
specified in SMBIOS 3.0. it would be more disruptive in this CL, as the change will also need to go in other other files where the table entry are used.
There's one file making use of struct smbios_entry: src/arch/x86/smbios.c Of course you would add a second struct for the 64bit entry point and keep the 32bit one.
I suggest having a later patch and review exclusively for the
table entry update.
|> It's not disruptive. Just a few lines to add in this file. No need to update the callers. It is disruptive indeed. For example the new "anchor" field is 5 bytes whereas the current one is 4 bytes. The 5 bytes of "formated area" , the 5 bytes of "intermediate anchor string" and the 1 byte of "intermediate checksum" all need to go away in 3.0 and one "reserve" byte need to come in. Even if it was just about updating the anchor string alone, changing its size here and not on the callers side will not work. Furthermore that smbios_entry struct is defined and used in at least two other different filee, hence my previous suggestion.
|> Commit message: Line 10: I can't find it on Gerrit. The hash was requested. Here is the full CL path, it hasn't been merge yet: https://chromium-review.googlesource.com/c/chromiumos/platform/mosys/+/15427...
I don't see how chromium patches relate to coreboot.
|> Commit message: Line 13: It does more than that. Yes, but that was just asummary of what the procedure does. If you have a better suggestion like Paul, I am happy to add it.
|>src/arch/x86/smbios.c: Line 279: Are you sure that all callers provide the value in MHz? They should. Per previous SMBIOS version specs, that speed have consistently been defined in MHZ. Even if other callers were mistakenly not providing it in MHz, then the fix most likely in other files, should be provided in other patches. Please sync up your comments with Nico's, he wants to reduce the number of changes in the patch. This cannot be achieved while fixing other stuffs as well.
If the callers should provide the value in the correct unit the SMBIOS spec defines, you should update all callers instead.