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

[Peter Robinson]

> > > > Maybe we need to turn this discussion on its head slightly. What do you
> > > > want to do to get SMBIOS fields to be widely populated with
> > > > generally-correct information? What we have been doing has seen very
> > > > little adoption so we need something else.
> > >
> > > Well, who or what is actually using this info? Is the problem just
> > > that it doesn't actually matter, so no one bothers? I'm just not sure.
> >
> > Users are using this information. Peter has explained that Fedora has
> > been carrying Ilias' original version of this patch since it was posted
> > so that bug reports say (something close enough and that can be tracked
> > down) what device they're on, rather than "Unknown" / "Unknown Product".
>
> Unfortunately I failed to get the latest Fedora running on rpi4. Is
> this the only ARM board it supports a download for? (I must be missing
> something)

We support 100s of devices, I replied to your query there. Let's keep
that conversation on that thread.

> Anyway, so this presumably requires EFI? If so, this is the kind of
> vertical integration and legacy promotion that really frustrates me.
> If not, then what is the mechanism to supply SMBIOS to user space?

I don't know what you mean by legacy in this context, UEFI is far from
legacy and is being actively developed, it's widely used across
enterprise and numerous other verticals. It seems by legacy you mean
"Not used by ChromeOS" sure

> I believe we have been here before, too. What program is used to
> collect the bug reports? Is it sos, perhaps?

There's literally 100s across enterprise platforms, some open, some
closed. Two used in Fedora are:
sosreport: https://github.com/sosreport/sos
cockpit management: https://github.com/cockpit-project/cockpit/

But even in Fedora there's dozens more and with enterprise management
platforms I suspect there's 100s or more.

> > > The fact that on ARM you cannot pass it to the kernel without EFI
> > > might be inhibiting its usefulness, too? Usefulness is the key
> > > question for me.
> >
> > I'm setting aside the discussion of how one will tell the kernel where
> > the SMBIOS is, outside of EFI as it's not a U-Boot problem and belongs
> > on other lists.
>
> OK, but in my mind this is a concern.
>
> >
> > > Anyway, my suggestion (once we understand why we care about SMBIOS
> > > tables) is patches like we just saw from rockpro64, perhaps even with
> > > a few more fields filled out. This series seems like a backup for
> > > board maintainers that don't care, which is fine, but we should at
> > > least be able to disable it.
> >
> > The issue is that this series adds, for free, useful and sufficiently
> > correct information in the common cases. The "for free" is a huge
> > feature too. Drawing on the rockpro64 patch, I would suggest seeing if
> > /version (or /hardware-rev or whatever) is something Rob is interested
> > in adding so it can be something filled out or not and then pulled from
> > DT instead of a new set of DT nodes that look a whole lot like the
> > existing DT nodes and properties that already exist.
>
> The new DT nodes / SMBIOS binding [1] allows for the correct
> information to be provided, though.

You are completely ignoring the numerous points that myself, Tom and
others have made.

> I'm fine with this as a Kconfig option, but it is a hack. It purports
> to provide SMBIOS info but (for both of the two fields it fills in) it
> is not in the correct format. It only works with EFI. If someone comes
> along and adds the proper info for a board, the name will change in
> the bug reports.

Keep beating that drum and ignoring everyone else's opinions. This
patch set in my opinion sets two fields, I have ideas around expanding
it out to fll out more of the information. Just like DM or numerous
other ideas you have they start with initial useful things and expand
with time.

> Which system-info tool is used? I see that hardinfo records the model
> [2] and produces a sensible name for the compatible string [3].
>
> Regards,
> Simon
>
> [1] https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/sysinfo/smbios.txt
> [2] https://github.com/lpereira/hardinfo/blob/master/modules/devices.c#L547
> [3] https://github.com/lpereira/hardinfo/blob/master/modules/devices/arm/processor.c#L433