# 27th June 2024, 6:00-7:00 UTC+0
https://ticket.coreboot.org/issues/542https://ticket.coreboot.org/issues/543https://ticket.coreboot.org/issues/545
Attendees: Joursoir, Anastasia
## Agenda
* 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.
Question: How can we avoid old chip models dragging down adding
new ones, without completely removing them from the database (some
users might still be using end-of-life chips)?
* probably wasn't an issue 20 years ago when flashchips.c was
designed, but now it is
* have a flag "end of life" for chip definition? by default, given
multiple definitions of the same model ID, the definition without a
flag be selected?
* vendors adding new model can mark old one end-of-life, in
the 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](https://ticket.coreboot.org/issues/…
* non-SPI chips are rarely used, and need special treatment in many
places in the code. The code for non-SPI (flashchips definitions,
parallel programmers, pieces of core logic) hasn't been updated or
maintained for many years, So there are no new chips added or new
features to the programmers.
* maybe we can create a separate repo "flashrom-non-spi" with all
the code. it will probably have 1 commit a year, or even less. The
rest of code (SPI and PROG) will be simplified, better tested and can
add new modern features
* it will be too confusing for users, they might not know what
they have, SPI or not
* two binaries is confusing too
* CONCLUSION: this idea is too wild, don't do this
* [joursoir] It would be nice to have a pretty table of supported
chips (like we had on the old wiki) on our website. Right now, there's
flashrom option that prints chips in html format, however we need to
rewrite it to rst so sphinx can use it. are there any pitfalls?
* we can do 2-step process: one step generates .rst file (logic
can be based on print.c), second step is normal build with
documentation, and sphinx will generate html file for the website.
* we can generate and publish html page with supported devices for
the latest release.
* developers who are interested what is supported at head, can
look into source code or run `flashrom -L` . no need to generate html
between releases.
* [joursoir] I will do it!
* ticket: [https://ticket.coreboot.org/issues/543](https://ticket.coreboot.org/issues/…
* How about, we split our large file flashchips.c into smaller files,
per manufacturer?
* seems like a good idea
* smaller files can get different maintainers per file => easier
to get attention to your patch for flashchip
* less merge conflicts
* easier to find chips, easier to maintain
* for example,
const struct flashchip flashchips[] = {
#include "chips/gigadevice.inc"
#include "chips/macronix.inc"
#include "chips/winbond.inc"
}
.inc is not valid c file, just a piece of code (slice array)
another idea can be array of .c files
* ticket: [https://ticket.coreboot.org/issues/545](https://ticket.coreboot.org/issues/…
--
Anastasia.
