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
