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

[Peter Robinson]

Hi  Simon,

Adding Rob for information around putting things in device tree.

> > If a value is not valid during the DT or SYSINFO parsing,  we explicitly
> > set that to "Unknown Product" and "Unknown" for the product and
> > manufacturer respectively.  It's cleaner if we move the checks insisde
> > smbios_add_string() and always report "Unknown" regardless of the missing
> > field.
> >
> > pre-patch dmidecode
> > <snip>
> > Handle 0x0001, DMI type 1, 27 bytes
> > System Information
> >         Manufacturer: Unknown
> >         Product Name: Unknown Product
> >         Version: Not Specified
> >         Serial Number: Not Specified
> >         UUID: Not Settable
> >         Wake-up Type: Reserved
> >         SKU Number: Not Specified
> >         Family: Not Specified
> >
> > Handle 0x0002, DMI type 2, 14 bytes
> > Base Board Information
> >         Manufacturer: Unknown
> >         Product Name: Unknown Product
> >         Version: Not Specified
> >         Serial Number: Not Specified
> >         Asset Tag: Not Specified
> >         Features:
> >                 Board is a hosting board
> >         Location In Chassis: Not Specified

> >         Type: Motherboard
> > <snip>
> >
> > post-patch dmidecode:
> >
> > Handle 0x0001, DMI type 1, 27 bytes
> > System Information
> >         Manufacturer: Unknown
> >         Product Name: Unknown
> >         Version: Unknown
> >         Serial Number: Unknown
> >         UUID: Not Settable
> >         Wake-up Type: Reserved
> >         SKU Number: Unknown
> >         Family: Unknown
> >
> > Handle 0x0002, DMI type 2, 14 bytes
> > Base Board Information
> >         Manufacturer: Unknown
> >         Product Name: Unknown
> >         Version: Unknown
> >         Serial Number: Not Specified
> >         Asset Tag: Unknown
> >         Features:
> >                 Board is a hosting board
> >         Location In Chassis: Not Specified
> >         Chassis Handle: 0x0000
> >         Type: Motherboard
> >
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> > ---
> >  lib/smbios.c | 17 +++--------------
> >  1 file changed, 3 insertions(+), 14 deletions(-)
>
> Perhaps a better fix is to drop the smbios info?
>
> 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.

Lots of things use it, particularly for enterprise support platforms.
The system-info apps you mention above are the GNOME about dialog box
and a tool called neofetch (which I personally don't particularly care
for but people like it for some reason).

There's general tools like dmidecode that use the information, but
there's a LOT of open source tools that use the SMBIOS information,
most of the Desktop UX About or HW tools, a lot of support tools like
sosreport (https://github.com/sosreport/sos), and server management
tools like cockpit (https://cockpit-project.org/) and uncountable
proprietary tools.

The problem with putting these things into Device Tree is that they're
not really describing the hardware explicitly and it's U-Boot specific
and Rob has mentioned in the past we absolutely shouldn't be making
things up that don't belong in Device Tree.

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

You say it's legacy, yet it released a new 3.6.0 version in June this
year and is used extensively across x86 and is required for some of
the Arm SystemReady standards. Doesn't appear particularly legacy to
me.

While I don't particularly like SMBIOS either it's the standard and
widely used, I don't see it going anywhere soon. The advantage of it
from someone who had to deal with end to end I feel it's better to
support this because patching all the various projects to support
other things and getting them deployed and enterprises and third
parties to upgrade and integrate into their platforms and processes.
Which from experience takes an extremely long time!

>     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.

I don't see this is any more pretty or any better than getting the
information from Device Tree, moving forward I think it would also be
useful to populate things like serial numbers from the fuse/otp blocks
which we often already display either on the console during boot for
via various commands.

Overall I think we need to be practical, this is a standard that is
widely used now, it's much more straight forward for the overall
ecosystem to continue to use a widely adopted standard rather than
trying to update all the open and proprietary tools out there to some
new "standard" that is only useful for device tree platforms. I'll
reference XKCD here for that: https://xkcd.com/927/

Peter