From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756386AbcIFTkK (ORCPT ); Tue, 6 Sep 2016 15:40:10 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:48279 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755283AbcIFTkJ (ORCPT ); Tue, 6 Sep 2016 15:40:09 -0400 Date: Tue, 6 Sep 2016 22:39:25 +0300 From: Dan Carpenter To: Arnd Bergmann Cc: Martyn Welch , Manohar Vanga , Greg Kroah-Hartman , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vme: fake: fix build for 64-bit dma_addr_t Message-ID: <20160906193925.GC4218@mwanda> References: <20160906130013.1616803-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160906130013.1616803-1-arnd@arndb.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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). regards, dan carpenter