[PATCH] libretech-cc: Populate SMBIOS information

[Neil Armstrong]

On 21/11/2023 15:09, Tom Rini wrote:
> 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.
> 

Thanks for the pointer, seems I had the exact same idea.
Hope this will be re-spinned, I don't want to add this to the 45 amlogic
boards when we have the necessary info already available and documented...

Neil