On 20 May 2015 at 09:43, Kevin Wolf <kw...@redhat.com> wrote: > Am 20.05.2015 um 10:06 hat Peter Maydell geschrieben: >> That handles migration, which is good. But I still think that >> storing the same information in two places in the device >> state (phase field and the register fields) is error-prone. > > That's actually my point. The registers are accessed everywhere in the > code, whereas phase transitions are in very few well-defined places > (there are exactly four of them, iirc). If they get out of sync, chances > are that the bug is in the register value, not in the phase. When we > know what phase we're in, we can assert the bits and actually catch such > bugs. > >> If we want to switch to having a phase field we should calculate >> the relevant register bits on demand based on the phase, rather >> than keeping both copies of the state in sync manually. > > That doesn't work, unfortunately. Some register bits imply a specific > phase (assuming correct code), but you can't derive the exact bits just > from the phase.
Having now dug out a copy of the 82078 spec, I agree that the state isn't derivable purely from the register values in the general case. The controller clearly has a state machine internally but it doesn't surface that in the register state except indirectly. -- PMM