The GSoC coding period has started and I have been working on my first
sub-project, adding support for 2nd status register. Most supported
chips that have multiple registers (around 80%) have opcode 0x35 for
reading SR2 and, opcode 0x01 for writing SR2. I have developed 3 models
and would like to have some feedback on them.
1. Integrate read/write SR2 with existing functions
- Define a feature bit FEATURE_SR2
- spi_read_status_register(), defined in spi25_statusreg.c, additionally
reads second status register depending on FEATURE_SR2 bit for that flash
- Change return to uint16_t for spi_read_status_register()
- spi_write_status_register_flag(), defined in spi25_statusreg.c,
considers higher byte of status to write to SR2, depending on
FEATURE_SR2 bit for that flash.
- Fits in elegantly with existing implementation (IMO). Most code in
flashrom stores status reads/writes in int, which can easily accommodate
the 16 bits
- Very little hassle when editing struct flashchip in flashchips.c
- RDSR will take more time - will read SR2 even if not needed
2. Define separate functions to read/write SR2
- Define spi_read_status_register2() to read only SR2
- Define spi_write_status_register2_flag() and
spi_write_status_register2() to write to SR2. This will read SR1 first,
then (SR2 << 8 | SR1) will be written using WRSR
- Flexibility (as compared to 1.)
- Need to write more lines (compared to 1.) when dealing with struct
3. struct status_register_layout
The ChromiumOS fork defines a struct status_register_layout in
writeprotect.c, which contains only BP and SRP bits' information.
Do a similar flashrom-wide definition, which contains all status
register bits' information.
- Very detailed representation of information
- Too much work when adding support for new chips
- Overhaul of existing infrastructure
IMHO, the first model is the best among these 3. I would like to know
what you guys think about these, whether you have some new idea. Looking
forward to your feedback. Thanks for your time.