On 05/20/2015 05:24 AM, Peter Maydell wrote: > 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 >
So even if /currently/ we can reconstitute it from the register values, we may eventually be unable to. post_load will work for now, but I fear the case (in ten years) when someone else cleans up FDC code but fails to realize that the phase is not explicitly migrated.
