[PATCH] libretech-cc: Populate SMBIOS information

[Tom Rini]

On Tue, Nov 21, 2023 at 02:46:29PM +0100, Neil Armstrong wrote:
> On 21/11/2023 14:15, Tom Rini wrote:
> > On Tue, Nov 21, 2023 at 10:18:04AM +0100, Neil Armstrong wrote:
> > > Hi Tom,
> > > 
> > > On 20/11/2023 21:16, Tom Rini wrote:
> > > > Enable CONFIG_SYSINFO_SMBIOS and populate the nodes so that Linux can
> > > > eventually display this information
> > > > 
> > > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > ---
> > > > Posting this as this was the easiest platform for me to test some SMBIOS
> > > > related patches on and I needed to populate the nodes so I could check
> > > > things in dmidecode once Linux was up.
> > > 
> > > Sorry to be late a the party, but can't this be dynamically found from DT's compatible & model ?
> > > Since I'll probably need to add this to all boards, it seems like a duplicate of what's already in the DT.
> > 
> > Part of the "fun" as to why we have the binding here is that while we
> > could use the top-level model property, there's not a corresponding one
> > for manufacturer. I'm fine ignoring the patch I posted here and having a
> > longer discussion about populating SMBIOS more usefully, globally, as I
> > think has been suggested a time or two.
> > 
> 
> I'm ok landing it with the same data as from the vendor.
> but couldn't we use the first top-level compatible as default smbios data ?
> 
> compatible = "vendor1,board-name", "vendor1,soc-name";
> 
> and translate to:
> 
> 
> smbios {
> 	system {
> 		manufacturer = "vendor1";
> 		product = "board-name";
> 	};
> 
> 	baseboard {
> 		manufacturer = "vendor1";
> 		product = "board-name";
> 	};
> 
> 	chassis {
> 		manufacturer = "vendor1";
> 		product = "board-name";
> 	};
> };
> 
> since the vendor name should be already documented in the linux
> bindings, same for the board name.
> And we would be free to add some custom data in the DT if needed.
> 
> Anyway, not sure it's the right place to discuss about that !

That's essentially
https://patchwork.ozlabs.org/project/uboot/patch/20220906134426.53748-2-ilias.apalodimas@linaro.org/
which had a bunch of comments on 1/2:
https://patchwork.ozlabs.org/project/uboot/patch/20220906134426.53748-1-ilias.apalodimas@linaro.org/

But I think that since then some thoughts on the subject have changed
and that approach might be more welcome now than it was then.

-- 
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/20231121/4ca664c9/attachment.sig>