Attention is currently required from: Edward O'Callaghan, Angel Pons, Anastasia Klimchuk, Sergii Dmytruk.
Patch set 7:Code-Review +1
1 comment:
Patchset:
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.
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.
To view, visit change 66211. To unsubscribe, or for help writing mail filters, visit settings.