[PATCH 00/10] SMBIOS improvements
Simon Glass
sjg at chromium.org
Mon Aug 26 21:12:16 CEST 2024
Hi Tom,
On Mon, 26 Aug 2024 at 12:23, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Aug 26, 2024 at 11:58:54AM -0600, Simon Glass wrote:
> > Hi Caleb,
> >
> > On Mon, 19 Aug 2024 at 17:03, Caleb Connolly <caleb.connolly at linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > > As a general comment, this is adding a load of code which is used by a
> > > > lot of platforms. As more and more aarch64 platforms are created, this
> > > > data grows. Why not use the devicetree for this hardware information?
> > > > That is what it is for.
> > >
> > > This data does not belong in devicetree, the various system registers
> > > exist to describe this information... Putting it in DT would be
> > > duplicating it.
> >
> > I am not wanting to duplicate info which can be read from system registers.
> >
> > >
> > > Using DT for this would additionally require having bindings accepted
> > > upstream and for all SoCs to add them. To what end?
> >
> > To get the correct information in there. How are boards supposed to
> > add SMBIOS info? Do we end up creating a whole infra in U-Boot just
> > for the driver to read it out? It just doesn't make any sense to me...
> >
> > Let's put hardware info in the DT where it belongs.
>
> I'm a little confused here because of some older threads on this overall
> topic. Part of the issue here is that in user space, "everyone" has
> SMBIOS-based tooling today, and wants to have that work, rather than
> inventing new tooling or modify existing tooling. And you were concerned
> I thought that we had tied SMBIOS too much to EFI being present when
> indeed it should be possible to pass the location along to the OS
> without EFI, but at the time Linux at least only supported that notion
> on MIPS I think?
That is a whole other concern I have, that we are perpetuating this
legacy format which is a real pain to work with, when we already have
devicetree. Let's leave that issue aside as I have not detected any
interest in solving that problem, or even any agreement that it is a
problem.
But for this particular series, I am just wanting to get the correct
info in there. Having the CPU-detection code provide an opinion about
what type of chassis is in use (just to take an example, the patch
pieces I highlighted have been dropped from the email I am replying
to) just seems a bit daft to me. Only the board vendor would know that
info.
Regards,
Simon
More information about the U-Boot
mailing list