On 17/10/23 14:52, Peter Maydell wrote:
On Tue, 17 Oct 2023 at 13:44, Philippe Mathieu-Daudé <[email protected]> wrote:
Hi Peter,
On 17/10/23 14:23, Peter Maydell wrote:
Currently for each button on the device we have a
StellarisGamepadButton struct which has the irq, keycode and pressed
state for it. When we convert to qdev, the qdev property and GPIO
APIs are going to require that we have separate arrays for the irqs
and keycodes. Convert from array-of-structs to three separate arrays
in preparation.
Signed-off-by: Peter Maydell <[email protected]>
---
hw/input/stellaris_gamepad.c | 43 ++++++++++++------------------------
1 file changed, 14 insertions(+), 29 deletions(-)
-static const VMStateDescription vmstate_stellaris_button = {
- .name = "stellaris_button",
- .version_id = 0,
- .minimum_version_id = 0,
- .fields = (VMStateField[]) {
- VMSTATE_UINT8(pressed, StellarisGamepadButton),
- VMSTATE_END_OF_LIST()
- }
-};
-
static const VMStateDescription vmstate_stellaris_gamepad = {
.name = "stellaris_gamepad",
.version_id = 2,
.minimum_version_id = 2,
.fields = (VMStateField[]) {
VMSTATE_INT32(extension, StellarisGamepad),
- VMSTATE_STRUCT_VARRAY_POINTER_INT32(buttons, StellarisGamepad,
- num_buttons,
- vmstate_stellaris_button,
- StellarisGamepadButton),
+ VMSTATE_VARRAY_UINT32(pressed, StellarisGamepad, num_buttons,
+ 0, vmstate_info_uint8, uint8_t),
Don't this break the migration stream?
Yes; this is OK because we don't care about migration compat
for this board. But I forgot to mention it in the commit
message, and we should bump the version_id fields too.
OK, this is what I thought (I'm still trying to correctly understand
that myself). With that updated:
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
