[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/5] hw/pxa2xx_dma.c: drop VMSTATE_UINTTL usage
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH 2/5] hw/pxa2xx_dma.c: drop VMSTATE_UINTTL usage |
Date: |
Wed, 22 Feb 2012 11:06:31 +0000 |
On 22 February 2012 10:15, Igor Mitsyanko <address@hidden> wrote:
> Convert variables descr, src and dest from type target_phys_addr_t to
> uint32_t,
> use VMSTATE_UINT32 instead of VMSTATE_UINTTL for these variables.
> We can do it safely because:
> 1) pxa2xx has 32-bit physical address;
> 2) rest of the code in this file treats these variables as uint32_t;
> 3) we shouldn't have used VMSTATE_UINTTL in the first place because this macro
> is for target_ulong type (which can be different from target_phys_addr_t).
>
> Signed-off-by: Igor Mitsyanko <address@hidden>
> ---
> hw/pxa2xx_dma.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/hw/pxa2xx_dma.c b/hw/pxa2xx_dma.c
> index 8ced0dd..0310154 100644
> --- a/hw/pxa2xx_dma.c
> +++ b/hw/pxa2xx_dma.c
> @@ -18,9 +18,9 @@
> #define PXA2XX_DMA_NUM_REQUESTS 75
>
> typedef struct {
> - target_phys_addr_t descr;
> - target_phys_addr_t src;
> - target_phys_addr_t dest;
> + uint32_t descr;
> + uint32_t src;
> + uint32_t dest;
> uint32_t cmd;
> uint32_t state;
> int request;
> @@ -512,9 +512,9 @@ static VMStateDescription vmstate_pxa2xx_dma_chan = {
> .minimum_version_id = 1,
> .minimum_version_id_old = 1,
> .fields = (VMStateField[]) {
> - VMSTATE_UINTTL(descr, PXA2xxDMAChannel),
> - VMSTATE_UINTTL(src, PXA2xxDMAChannel),
> - VMSTATE_UINTTL(dest, PXA2xxDMAChannel),
> + VMSTATE_UINT32(descr, PXA2xxDMAChannel),
> + VMSTATE_UINT32(src, PXA2xxDMAChannel),
> + VMSTATE_UINT32(dest, PXA2xxDMAChannel),
> VMSTATE_UINT32(cmd, PXA2xxDMAChannel),
> VMSTATE_UINT32(state, PXA2xxDMAChannel),
> VMSTATE_INT32(request, PXA2xxDMAChannel),
> --
Reviewed-by: Peter Maydell <address@hidden>
These are clearly intending to model 32 bit registers so we shouldn't
be tying them to target_phys_addr_t (which would probably break things
if/when we ever move to target_phys_addr_t being 64 bits for all things).
-- PMM