Re: [PATCH] vme: fake: fix build for 64-bit dma_addr_t

[Arnd Bergmann]

On Tuesday, September 6, 2016 10:39:25 PM CEST Dan Carpenter wrote:
> On Tue, Sep 06, 2016 at 02:59:41PM +0200, Arnd Bergmann wrote:
> > casting between dma_addr_t and a pointer is generally tricky,
> > as they might not be the same size and almost never point into
> > the same address space. With 32-bit ARM systems and LPAE, we
> > get this warning for the vme_fake driver that stores a pointer
> > in a dma_addr_t variable:
> > 
> > drivers/vme/bridges/vme_fake.c: In function 'fake_slave_set':
> > drivers/vme/bridges/vme_fake.c:204:29: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
> > 
> > To make this clearer while fixing the warning, I'm adding
> > a set of helper functions for the type conversion.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> > ---
> >  drivers/vme/bridges/vme_fake.c | 26 ++++++++++++++++++--------
> >  1 file changed, 18 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/vme/bridges/vme_fake.c b/drivers/vme/bridges/vme_fake.c
> > index 7ef298b289f4..ebf35d305321 100644
> > --- a/drivers/vme/bridges/vme_fake.c
> > +++ b/drivers/vme/bridges/vme_fake.c
> > @@ -48,7 +48,7 @@ struct fake_slave_window {
> >       int enabled;
> >       unsigned long long vme_base;
> >       unsigned long long size;
> > -     dma_addr_t buf_base;
> > +     void *buf_base;
> 
> This shouldn't be u64?  (I don't know the answer).

I changed it to 'void *' because it gets accessed as a pointer in kernel
space. It gets passed through the vme core code in a dma_addr_t, but
it seemed easier to do the conversion at the time it gets passed in and
out rather than the time it gets accessed.

An alternative that would work equally well is to make it uintptr_t.

	Arnd