Re: [PATCH 1/2] smbios: Simplify reporting of unknown values

Hi Simon,

[...]

...

Signed-off-by: Ilias Apalodimas ilias.apalodimas@linaro.org

lib/smbios.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-)

Perhaps a better fix is to drop the smbios info?

Unfortunately there's a ton of userspace tools still using it. So I think we still need it

What upstream projects use this information to show things to the user? You showed a screenshot of some sort of system-info app. We could teach it about falling back to the device tree. That way we are not adding fake information to SMBIOS.

What's fake here? The model and compatible are taken directly from the DT and that should be accurate. I'd rather fix the DT if that's problematic. What would make sense for me to change is take the first token of the compatible node instead of the entire string as it's format is expected to be <manufacturer, model> anyway.

Also, SMBIOS is a legacy thing and a PITA to work with. How about we use the device tree binding for the same info:

smbios {
    compatible = "u-boot,sysinfo-smbios";

    smbios {
        system {
            manufacturer = "pine64";
            product = "rock64_rk3328";
        };

        baseboard {
            manufacturer = "pine64";
            product = "rock64_rk3328";
        };

        chassis {
            manufacturer = "pine64";
            product = "rock64_rk3328";
        };
    };
};

This is easy to parse and gets us away from all this legacy junk that we don't need.

That's the exact opposite of the patch description. Most of these info are already included in the DT in it's standard properties. So if U-Boot ends up with a DT without these we get a usable smbios table. For example a DT handed over by the previous stage bootloader would not include these nodes.

As far as sysinfo-smbios node is concerned, it's only present in 13 boards, so it's not like it's used by the majority of boards. Yes we could fix them, but imho we are better off re-using what's already there and defined on the DT spec at least for the simplistic values.

Thanks /Ilias

Regards, Simon