Attention is currently required from: Edward O'Callaghan, Angel Pons, Anastasia Klimchuk, Sergii Dmytruk.
Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/66211 )
Change subject: spi25_statusreg: support reading/writing "configuration registers" ......................................................................
Patch Set 7: Code-Review+1
(1 comment)
Patchset:
PS2:
So what are we doing here in the end? Aliasing or no aliasing?
Even without the `CONFIGx` names, register to opcode mapping is not 1:1. It may be almost 1:1 right now by coincidence for the chips in our table. But generally it's whatever chip vendors choose it to be. So this holds for `CONFIG1` and `STATUS2` the same, for instance.
* may or may not use the common opcode `0x01` (WRSR) with extended length * may or may not use the common opcode `0x31` (WRSR2)
We just don't know what it is. So the idea was to have at least a 1:1 mapping for datasheet names and flashrom names. An alternative would be to encode the opcode in the `enum flash_reg` name. But that's orthogonal to the `CONFIGx` aliasing. Because for the Spansion chips `CONFIG1` would mean exactly the same as `STATUS2`. AIUI, the odd chip in question `MX25L6473F` would need something like `CONFIG1_RDCR_0x15`? (if we want a 1:1 mapping from names to opcodes, but then `STATUS1/2` should probably be split too to tell what opcodes are valid to write them?)
I would prefer to keep the names/aliases with separate flags to decide the opcodes used, so that `.reg_bit` definitions stay legible. Otherwise we would also repeat the opcode for every bit defined and that redundancy would need additional consistency checks.