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

[Tom Rini]

On Tue, Dec 19, 2023 at 09:46:22PM -0700, Simon Glass wrote:
> Hi again,
> 
> On Mon, 18 Dec 2023 at 14:07, Simon Glass <sjg at chromium.org> wrote:
> >
> > 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?
> 
> Hmmm and I forgot the other problem, which is that there is no way to
> pass an SMBIOS table to Linux without booting via EFI. But I don't
> follow it closely, so perhaps that has been resolved?

This issue here is firmly NOT a U-Boot problem. It's a problem for
whomever wants to, I assume, design and upstream a DT binding to
describe how to find a populated SMBIOS table? There is IIRC some
MIPS-specific Linux Kernel option, but I imagine it wouldn't be allowed
to be added to other architectures as I assume it's magic location based
like non-EFI x86 ones?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231220/6c911ba2/attachment.sig>