On 8/26/24 20:23, Tom Rini 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.conno...@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?
Looking at the Linux kernel code, only x86 can discover an SMBIOS table
without EFI. We should not ride that dead horse.
Best regards
Heinrich
