From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Cp4-0002kd-6p for qemu-devel@nongnu.org; Wed, 22 Feb 2012 09:05:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0Coy-0004n0-RZ for qemu-devel@nongnu.org; Wed, 22 Feb 2012 09:05:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Coy-0004mn-J5 for qemu-devel@nongnu.org; Wed, 22 Feb 2012 09:05:28 -0500 From: Juan Quintela In-Reply-To: (Peter Maydell's message of "Wed, 22 Feb 2012 13:52:13 +0000") References: <1329905754-11873-1-git-send-email-i.mitsyanko@samsung.com> <1329905754-11873-3-git-send-email-i.mitsyanko@samsung.com> <87ty2jugiw.fsf@elfo.elfo> Date: Wed, 22 Feb 2012 15:05:24 +0100 Message-ID: <8762ezufob.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/5] hw/pxa2xx_dma.c: drop VMSTATE_UINTTL usage Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: balrog@zabor.org, Igor Mitsyanko , e.voevodin@samsung.com, qemu-devel@nongnu.org, kyungmin.park@samsung.com, d.solodkiy@samsung.com, m.kozlov@samsung.com, afaerber@suse.de Peter Maydell wrote: > On 22 February 2012 13:47, Juan Quintela wrote: >> Igor Mitsyanko 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). >> >> This is an incompatible change, we need to bump the version. > > Why? For the cases where this device is used, target_phys_addr_t is > always 32 bits so we aren't changing anything, surely? You are right, I had jsut forgot that this device is only used in ARM. I stand corrected. Later, Juan.