Anastasia Klimchuk aklm@chromium.org writes:
- As the time goes, chip vendors are producing newer models, which
sometimes re-use model IDs of old versions. Old versions are considered as "end of life", and replaced with newer models with more features. However flashchips.c accumulates everything and with time we get more and more duplicate model IDs. This makes adding new models harder, but also increases the chance users need to manually specify the chip model.
Reusing IDs for things that are not the same is a really unfortunate practice. I can't sew how that would lead to anyting but trouble, for anybody's update code. I think it would be good for the project to somehow ask the manufacturers not to do this, if that's comfortable.
Question: How can we avoid old chip models dragging down addingnew ones, without completely removing them from the database (some users might still be using end-of-life chips)?
This question seems very strange to me. The point of a program like flashrom is to support the hardware that people have, and "end-of-life" in chips usually seems like "we are not longer making this chip", not "anyone who has a device containing this chip should immediately stop using it and take it to recycling".
The question should then be two
Given that chip vendors have the buggy practice of reusing IDs for different chips, what kind of UI and configuration is appropriate so that flashrom users can use the program safely and effectively.
Are there chips whose IDs have been reused that we are willing to say that essentially none of them are in service, so that flashrom can just treat any with that ID as the new version? This is a combination of "will doing this brick the old ones" and "how many are there". This is really a secondary question; the main one is how to use both.
* have a flag "end of life" for chip definition? by default, givenmultiple definitions of the same model ID, the definition without a flag be selected?
I don't really see "end of life" as the real issue. I see it as "chip vendor has shipped two kinds of chips with the same ID and we need to invoke some further disambiguation mechanism before we operate on it".
The fact that they did it because they stopped selling the other one, rather than that they did it because they are just confused, is not really relevant. The only thing that matters is that when flashrom reads that ID, it does not know what chip it is dealing with.
* vendors adding new model can mark old one end-of-life, inthe same patch * [joursoir] It doesn't bother me. maybe it's not a big problem? but just having a flag "end-of-life" for information might be useful * need to be a good clear name, because flashrom still supports everything! * separate file flashchips_legacy.c for old chips? * bad: moving definitions from one file to another is pita * CONCLUSION: maybe we can add a flag to flashchip struct and no changes to probing logic yet. * ticket: [https://ticket.coreboot.org/issues/542%5D(https://ticket.coreboot.org/issues...)
This all feels off, reasoning from vendor eol being reasonable and trying to record that, vs thinking about users and hardware likely to be encountered.
What are you going to do with the eol flag? Consider a manufacturer that stops selling a chip and thus it is EOL, but that they have good management practices and do not reuse the ID. It seems like you should set the flag. What then happens at runtime? Do you tell the user "the flash chip in your computer is no longer manufactured"?? I would think that almost all computers in use are no longer manufactured, unless they are super new.
The real issue is "there are two chips with this id", and this is not about EOL. In that case, the chip structure needs to have a flashrom_revision_code value to separate them, remediating the manufacturer's choice to reuse, and the user needs to configure
manufacturer_id: flashrom_revision_code
in a config file so the match will lead to using the right definition.