Hi Neil,
On Tue, 21 Nov 2023 at 16:43, Neil Armstrong <neil.armstr...@linaro.org> wrote:
>
> 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 <tr...@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.apalodi...@linaro.org/
> > which had a bunch of comments on 1/2:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220906134426.53748-1-ilias.apalodi...@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...
I'll respin the patches Tom mentioned once I find some time to address
the comments in v1. Hope to do it by the end of the week
Cheers
/Ilias
>
> Neil
>
