[PATCH 2/2 v2] smbios: Fallback to the default DT if sysinfo nodes are missing
Simon Glass
sjg at chromium.org
Wed Dec 20 18:31:47 CET 2023
Hi Peter,
On Tue, 19 Dec 2023 at 13:23, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> > > > > What do you mean wrong, exactly?
> > > >
> > > > "raspberrypi" instead of "Raspberry Pi", for example, or "friendlyarm"
> > > > instead of "FriendlyElec"
> > >
> > > Heh, well, even in the x86 world vendors can't even spell their own
> > > name consistently.
> > >
> > > > I just wonder what this information is actually used for. If it is
> > > > just for fun, that is fine, but I believe some tools do use dmidecode,
> > > > at which point it needs to be accurate and should not change later,
> > > > e.g. when someone decides to actually add the info.
> > >
> > > So the Linux kernel uses this information to apply quirks for specific
> > > machines. But I hope that on platforms that have a device tree folks
> > > will just use the board compatible string for that purpose.
> >
> > Right.
> >
> > >
> > > Otherwise I think this information is mostly used to populate system
> > > information UIs and asset databases.
> >
> > So perhaps the devicetree should be used instead? How do these things
> > work today? And what are they, exactly?
>
> Device tree used for what? To populate the SMBIOS tables? Or to
> populate "system information UIs and asset databases."
>
> If you mean the later, that is not going to work. These platforms are
> often proprietary, and are generally remote. They have local agents
> that use dmidecode to populate things for support and management. It's
> kind of in the name "System Management". To get all these platforms
> updated to "just use devicetree" will take decades. No thanks!
Do we care about these platforms? Do we even know what they are? Do
they even run on ARM?
I found a thing called 'sos' and it does actually use the devicetree,
which is actually the correct thing to do, on platforms which use
device tree.
At this point I'm wondering what problem is being solved here? We know
we cannot pass the SMBIOS table without EFI in any case. A huge
argument in Linux with hundreds of emails results in 'no patch
applied', so far as I am aware. At the very least, that seems odd.
Just to restate my suggestions:
- Put this feature behind an #ifdef
- Allow people to add the authoritative info if they want to
- Add something to the SMBIOS info that indicates it is provisional /
auto-generated
- Figure out how to handle this when booting without EFI (or decide
that SMBIOS is not used then?)
- minor: simplify the code to just handle the two pieces of info
currently decoded; add tests
Do you agree with any or all of those?
Regards,
Simon
More information about the U-Boot
mailing list