Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753305AbbDPRCT (ORCPT ); Thu, 16 Apr 2015 13:02:19 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:22394 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbbDPRCJ (ORCPT ); Thu, 16 Apr 2015 13:02:09 -0400 Date: Thu, 16 Apr 2015 20:01:44 +0300 From: Dan Carpenter To: Geert Uytterhoeven Cc: Peter Senna Tschudin , driverdevel , Greg Kroah-Hartman , Jun Tian , "linux-kernel@vger.kernel.org" , Andreas , Garret Kelly , Octavian Purdila , Nick Kralevich , Alan Subject: Re: [PATCH V4] Fix pointer cast for 32 bits arch Message-ID: <20150416170144.GM10964@mwanda> References: <20150413122911.GW10964@mwanda> <1429191546-1398-1-git-send-email-peter.senna@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1583 Lines: 35 On Thu, Apr 16, 2015 at 06:14:55PM +0200, Geert Uytterhoeven wrote: > On Thu, Apr 16, 2015 at 3:39 PM, Peter Senna Tschudin > wrote: > > --- a/drivers/staging/goldfish/goldfish_audio.c > > +++ b/drivers/staging/goldfish/goldfish_audio.c > > @@ -63,7 +63,7 @@ struct goldfish_audio { > > #define AUDIO_READ(data, addr) (readl(data->reg_base + addr)) > > #define AUDIO_WRITE(data, addr, x) (writel(x, data->reg_base + addr)) > > #define AUDIO_WRITE64(data, addr, addr2, x) \ > > - (gf_write64((u64)(x), data->reg_base + addr, data->reg_base+addr2)) > > + (gf_write_ptr((void *)(x), data->reg_base + addr, data->reg_base+addr2)) > > This one should not be converted, as all callers pass a dma_addr_t, which may > be 64-bit on 32-bit systems, i.e. larger than void *. Ugh... You're right. I've been avoiding asking this but I can't any longer. What is gf_write64() actually doing? We are writing dma addresses, user space pointers and kernel space pointers to this hardware? This stuff doesn't seem to make any kind of sense and I can easily imagine a situation where it wrote a 64 bit pointer. Then we partially write over it with a 32 bit userspace pointer. Then it writes somewhere totally unintended. This thing doesn't make any sort of sense to me. regards, dan carpenter -- 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/