On Sun, 21 Dec 2025 at 06:27, <[email protected]> wrote: > > Signed-off-by: Alano Song <[email protected]> > --- > hw/i2c/allwinner-i2c.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/hw/i2c/allwinner-i2c.c b/hw/i2c/allwinner-i2c.c > index fe887e1c6a..728b7e622f 100644 > --- a/hw/i2c/allwinner-i2c.c > +++ b/hw/i2c/allwinner-i2c.c > @@ -419,10 +419,12 @@ static const VMStateDescription allwinner_i2c_vmstate = > { > VMSTATE_UINT8(xaddr, AWI2CState), > VMSTATE_UINT8(data, AWI2CState), > VMSTATE_UINT8(cntr, AWI2CState), > + VMSTATE_UINT8(stat, AWI2CState), > VMSTATE_UINT8(ccr, AWI2CState), > VMSTATE_UINT8(srst, AWI2CState), > VMSTATE_UINT8(efr, AWI2CState), > VMSTATE_UINT8(lcr, AWI2CState), > + VMSTATE_BOOL(irq_clear_inverted, AWI2CState), > VMSTATE_END_OF_LIST() > }
It isn't valid to add new vmstate fields without changing the vmstate version number, because this breaks migration compatibility. For a board like the allwinner ones where we don't need to retain migration compatibility across versions, it is good enough to increase the version and minimum-version number when making the change. You won't be able to load/restore the state data across the change, but it will fail with a reasonable error message. The commit message should note the compatibility break and which machine types it applies to. Speaking of commit messages, it would also be useful here to say: * what is the (user-visible) problem this is fixing * which commit the problem was introduced in * whether it is worth back-porting this to stable releases thanks -- PMM
