Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753757AbbDMJQ6 (ORCPT ); Mon, 13 Apr 2015 05:16:58 -0400 Received: from mail-la0-f51.google.com ([209.85.215.51]:34780 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753602AbbDMJQv (ORCPT ); Mon, 13 Apr 2015 05:16:51 -0400 MIME-Version: 1.0 In-Reply-To: <20150413091019.GS10964@mwanda> References: <1428830803-30896-1-git-send-email-peter.senna@gmail.com> <20150413091019.GS10964@mwanda> Date: Mon, 13 Apr 2015 11:16:49 +0200 Message-ID: Subject: Re: [PATCH] Fix pointer cast for 32 bits arch From: Peter Senna Tschudin To: Dan Carpenter Cc: Greg Kroah-Hartman , Loic Pefferkorn , Alan , Jun Tian , Octavian Purdila , Garret Kelly , =?UTF-8?Q?Kristina_Mart=C5=A1enko?= , Nick Kralevich , driverdevel , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3488 Lines: 85 On Mon, Apr 13, 2015 at 11:10 AM, Dan Carpenter wrote: > On Sun, Apr 12, 2015 at 11:26:43AM +0200, Peter Senna Tschudin wrote: >> Sparse compalins about casting void * to u64 on i386. >> Change the cast to resource_size_t. >> >> Signed-off-by: Peter Senna Tschudin >> --- >> >> Tested by compilation only. Tested for x86 and x86_64. >> >> drivers/staging/goldfish/goldfish_nand.c | 3 ++- >> include/linux/goldfish.h | 2 +- >> 2 files changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/staging/goldfish/goldfish_nand.c b/drivers/staging/goldfish/goldfish_nand.c >> index d68f216..738fdc4 100644 >> --- a/drivers/staging/goldfish/goldfish_nand.c >> +++ b/drivers/staging/goldfish/goldfish_nand.c >> @@ -87,7 +87,8 @@ static u32 goldfish_nand_cmd(struct mtd_info *mtd, enum nand_cmd cmd, >> writel((u32)(addr >> 32), base + NAND_ADDR_HIGH); >> writel((u32)addr, base + NAND_ADDR_LOW); >> writel(len, base + NAND_TRANSFER_SIZE); >> - gf_write64((u64)ptr, base + NAND_DATA, base + NAND_DATA_HIGH); >> + gf_write64((resource_size_t)ptr, base + NAND_DATA, >> + base + NAND_DATA_HIGH); > > write64 is a misleading name because it only writes 32 bits on 32 bit > systems. > > Are you sure it's a resource_size_t? If that's really true then this > code needs a lot more work. The ifdef in gf_write64() should be > CONFIG_PHYS_ADDR_T_64BIT and ops->datbuf needs to updated. It would be > a lot of changes... > > I *think* but I'm not positive that gf_write64 should just take a void > pointer like this: > > diff --git a/drivers/staging/goldfish/goldfish_nand.c b/drivers/staging/goldfish/goldfish_nand.c > index 213877a..92d6479 100644 > --- a/drivers/staging/goldfish/goldfish_nand.c > +++ b/drivers/staging/goldfish/goldfish_nand.c > @@ -87,7 +87,7 @@ static u32 goldfish_nand_cmd(struct mtd_info *mtd, enum nand_cmd cmd, > writel((u32)(addr >> 32), base + NAND_ADDR_HIGH); > writel((u32)addr, base + NAND_ADDR_LOW); > writel(len, base + NAND_TRANSFER_SIZE); > - gf_write64((u64)ptr, base + NAND_DATA, base + NAND_DATA_HIGH); > + gf_write64(ptr, base + NAND_DATA, base + NAND_DATA_HIGH); > writel(cmd, base + NAND_COMMAND); > rv = readl(base + NAND_RESULT); > } > diff --git a/include/linux/goldfish.h b/include/linux/goldfish.h > index 569236e..4cdb913 100644 > --- a/include/linux/goldfish.h > +++ b/include/linux/goldfish.h > @@ -3,12 +3,12 @@ > > /* Helpers for Goldfish virtual platform */ > > -static inline void gf_write64(unsigned long data, > +static inline void gf_write64(void *data, > void __iomem *portl, void __iomem *porth) > { > - writel((u32)data, portl); > + writel((u32)(unsigned long)data, portl); > #ifdef CONFIG_64BIT > - writel(data>>32, porth); > + writel((unsigned long)data >> 32, porth); > #endif > } > I like this solution. Should I send a single patch changing gf_write64() and removing all casts when calling the gf_write64(), or if to split, how to split the patch? -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/