public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Tom Rini <trini@konsulko.com>,
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	Peter Robinson <pbrobinson@gmail.com>
Subject: Re: [PATCH 1/2] smbios: Simplify reporting of unknown values
Date: Fri, 16 Sep 2022 23:30:30 +0300	[thread overview]
Message-ID: <YyTc5tR9IbGzDlYa@hera> (raw)
In-Reply-To: <CAPnjgZ0jw3VdJTi5+oX=JLL=DLTGJDzcKt+8imv=G10KorTg9w@mail.gmail.com>

Hi Simon,

[...]

> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > ---
> >  lib/smbios.c | 17 +++--------------
> >  1 file changed, 3 insertions(+), 14 deletions(-)
> 
> Perhaps a better fix is to drop the smbios info?

Unfortunately there's a ton of userspace tools still using it.  So I think
we still need it

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

What's fake here?  The model and compatible are taken directly from the DT
and that should be accurate.  I'd rather fix the DT if that's problematic.
What would make sense for me to change is take the first token of the
compatible node instead of the entire string as it's format is expected to
be <manufacturer, model> anyway.

> Also, SMBIOS is a legacy thing and a PITA to work with. How about we
> use the device tree binding for the same info:
> 
>     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.

That's the exact opposite of the patch description.  Most of these info are
already included in the DT in it's standard properties.  So if U-Boot ends
up with a DT without these we get a usable smbios table.  For example a DT 
handed over by the previous stage bootloader would not include these nodes.

As far as sysinfo-smbios node is concerned,  it's only present in 13
boards, so it's not like  it's used by the majority of boards.  Yes we
could fix them, but imho we are better off re-using what's already there
and defined on the DT spec at least for the simplistic values.

Thanks
/Ilias
> 
> Regards,
> Simon

  reply	other threads:[~2022-09-16 20:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 13:44 [PATCH 1/2] smbios: Simplify reporting of unknown values Ilias Apalodimas
2022-09-06 13:44 ` [PATCH 2/2] smbios: Fallback to the default DT if sysinfo nodes are missing Ilias Apalodimas
2022-09-20 11:10   ` Peter Robinson
2022-09-29  9:59     ` Simon Glass
2022-09-29 10:23       ` Ilias Apalodimas
2022-09-29 23:55         ` Simon Glass
2022-09-30  9:56           ` Mark Kettenis
2022-09-30 14:51             ` Tom Rini
2022-09-12 18:31 ` [PATCH 1/2] smbios: Simplify reporting of unknown values Simon Glass
2022-09-16 20:30   ` Ilias Apalodimas [this message]
2022-09-17 16:55     ` Sean Anderson
2022-09-26 10:56       ` Ilias Apalodimas
2022-09-29  4:34         ` Sean Anderson
2022-09-29  9:59           ` Simon Glass
2022-09-29 14:02             ` Sean Anderson
2022-09-30 14:25               ` Tom Rini
2022-09-29 10:09           ` Ilias Apalodimas
2022-09-20 10:15   ` Peter Robinson
2022-09-20 11:09 ` Peter Robinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YyTc5tR9IbGzDlYa@hera \
    --to=ilias.apalodimas@linaro.org \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=pbrobinson@gmail.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox