[PATCH 00/10] SMBIOS improvements

[Tom Rini]

On Mon, Aug 26, 2024 at 01:12:16PM -0600, Simon Glass wrote:
> 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.

OK, yes, lets set that aside.

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

Yes, I agree the detection should be reworked a good bit as some
information will be board design specific while others SoC specific. And
we should avoid adding many unused at run time strings to all platforms
that enable this too (looking at all the CPU vendor related stuff).

-- 
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/20240826/b8450eef/attachment.sig>