[PATCH 1/2 v2] smbios: Simplify reporting of unknown values

[Peter Robinson]

Hi Simon,

> > > > > Hmm I don't know, but I wonder why I am not just checking t->bios_ver for Unknown.
> > > > > I'll have a look and change it
> > > >
> > > > Ok, this can't be changed as easily.  smbios_add_prop() will not
> > > > return NULL in any case. It returns an integer. With the cleanup, it
> > > > will always writes 'Uknown' and not return 0 anymore.
> > > > I can add that default value you suggested but the ctx->last_str is
> > > > still used on the next line anyway.
> > >
> > > Would you mind if I tried to create a version of the patch which does
> > > the same thing but with less code, and perhaps a test? It might be
> > > easier to discuss it then. I can't claim to understand all the
> > > different code paths at this point.
> > >
> > > My main concern is that with so many code paths it will be hard even
> > > to refactor the code in the future, since it will become
> > > 'load-bearing' and anyone might turn up and say it breaks their board
> > > because different information is provided.
> >
> > I don't buy this argument at all, sorry.
>
> OK.
>
> >
> > > Overall, so long as the information isn't used for anything important
> > > in userspace, and we find a way to report SMBIOS to Linux without EFI,
> >
> > No, you can't tie random requirements to improving the SMBIOS support.
> > We *already* report SMBIOS to Linux, reporting SMBIOS to Linux without
> > EFI is changing things that will need different or extra standards,
> > that could take years.
> >
> > You are arbitrarily adding extra requirements just to suite yourself,
> > please STOP trying to hold things like this hostage.
>
> Isn't that what is happening with Linux and ffi? My understanding is
> that there is no way to pass SMBIOS to Linux without EFI. Is that
> correct? I know some people at their wit's end about that.

Maybe the uses that want to go from a minimal firmware straight to a
minimal kernel don't care about SMBIOS tables for their use cases,
things don't need to be full parity to move forward the existing well
defined usecase.

> You may know that I have tried for years to get bindings upstream to
> Linux....right now there is a reserved-memory binding which has been
> held up for longer than I can remember, because of EFI. How about a
> little give and take?

I actually caught up on the reserved-memory binding thread a week or
so ago and my general thoughts from that thread was that there was a
lot of outstanding questions being asked of you that you haven't
clearly articulated or even replied to and the thread ended with you
asking a number of times "can this be merged now?" and my thought at
the time was "No, because there's a bunch of outstanding details". May
I suggest you re-read that thread and take some notes while you do so
and make sure all the outstanding questions have been answered and
reply with a single response addressing the remaining details, from
there we may be able to move on.

> >
> > > it is OK to enable this feature (with a new Kconfig so it can be
> > > disabled). But there is already authoritative info in the DT, so this
> >
> > There is two types of information in DT, the smbios "entries" in DT
> > are not standardised in the dtschema and in most cases they're
> > unnecessarily replicating data ALREADY in DT which is being produced
> > automatically with these patches, making it zero effort for vendors to
> > produce.
> >
> > > transformation into SMBIOS really should just be used for user
> > > display, etc., not for anything which affects operation of the device.
> >
> > Well SMBIOS tables are used for a number of different things already
> > in the kernel.
> >
> > > Do you agree? If you do, how to ensure that? Perhaps a special string
> > > in the table like 'GENERATED'?
> >
> > Nope, I do not agree, at all.
>
> OK, well there it is.
>
> Anyway, as I said, I am happy for this to go in with a Kconfig
> controlling it (so it can be enabled/disabled). Then SoCs that don't
> want to go to the bother of adding authoritative info can just enable
> this Kconfig.
>
> I would very much like to see some signal that it is not
> authoritative. That should not be a big imposition.
>
> For my own interest, I would like to understand what actually uses it
> as I suspect it is just for display. The two programs I managed to
> find both handle devicetree and don't need SMBIOS.
>
> Regards,
> Simon