[PATCH 2/2 v3] smbios: Fallback to the default DT if sysinfo nodes are missing

[Simon Glass]

Hi Neil,

On Mon, 18 Dec 2023 at 08:37, <neil.armstrong at linaro.org> wrote:
>
> Hi,
>
> On 18/12/2023 16:01, Simon Glass wrote:
> > Hi Neil,
> >
> > On Mon, 18 Dec 2023 at 02:54, <neil.armstrong at linaro.org> wrote:
> >>
> >> On 17/12/2023 19:41, Tom Rini wrote:
> >>> On Sat, Dec 16, 2023 at 11:46:18AM -0700, Simon Glass wrote:
> >>>> Hi Tom,
> >>>>
> >>>> On Thu, 14 Dec 2023 at 06:11, Tom Rini <trini at konsulko.com> wrote:
> >>>>>
> > [..]
> >
> >>> And my point with the above is that other SoC maintainers (Neil, for
> >>> amlogic) have said (paraphrasing) he does not want to do N smbios node
> >>> patches. Which is why Ilias' patch is if not 1000% correct, it's Good
> >>> Enough and will, if it's really a problem to have all lower case
> >>> information displayed, spur people to see providing that information as
> >>> a real problem that needs to be solved. Or it will be seen as good
> >>> enough.
> >>>
> >>
> >> If some platforms requires a more "correct" smbios dataset, then they're
> >> welcome adding the required smbios node, and it's perfectly understandable,
> >> but for the other community-maintained platforms we need some valid fallback
> >> data otherwise they'll be de facto excluded from some tools for no valid reasons.
> >
> > Do you know which tools require SMBIOS tables? I found sos and another
> > Redhat one.
>
> SMBIOS data is translated into dmi informations in Linux, and a little
> lookup in GitHub gives 6.4K files using something from /sys/devices/virtual/dmi/id/,
> and by very commonly used tools like lshw and probably fwupd.

lshw also uses devicetree, so should not also need SMBIOS.

fwupd uses UUIDs to indicate the device. So far as I know (and I wrote
a plugin for it, so at least know something), it does not rely on
SMBIOS tables.

Here is my main question: is SMBIOS:

1) just informational, not affecting the operation of the device
2) important and needed for the device to function

If it is (1), then I don't mind what is in the tables - we could
perhaps add a '?' at the start of each string to indicate it is
provisional?
If it is (2), then I want to avoid adding information that might be
wrong / might change over the life of the device

In either case, putting these workarounds behind a Kconfig seems
reasonable to me. What do you think?

Regards,
Simon