Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753262Ab0LLOD4 (ORCPT ); Sun, 12 Dec 2010 09:03:56 -0500 Received: from mail-wy0-f174.google.com ([74.125.82.174]:37304 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753092Ab0LLODy convert rfc822-to-8bit (ORCPT ); Sun, 12 Dec 2010 09:03:54 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PmK8FRxTyWLyDrAreJjfpCQEhnJEhpncdc+c+EGeN/T56a9e5Au7VjMVaYrRFqx2oc 4+5g+ssIlld/nXVhqDhnIlzx2CrXxtNKyK5NQWrZOTLmeW0dG+EBMn2136YeWUU6eJt5 CPEtLJ1KKPWXVlErIukhXBzSdpaHHFoyQ25EI= MIME-Version: 1.0 In-Reply-To: <20101212135224.GA31812@void.printf.net> References: <20101208115510.GD10998@console-pimps.org> <20101209064751.GA21128@void.printf.net> <20101209160157.GA28586@void.printf.net> <20101211192320.GA24430@void.printf.net> <20101212135224.GA31812@void.printf.net> Date: Sun, 12 Dec 2010 14:03:52 +0000 Message-ID: Subject: Re: [PATCH] dw_mmc: Add Synopsys DesignWare mmc host driver. From: Will Newton To: Chris Ball Cc: Linux Kernel list , linux-mmc@vger.kernel.org, Matt Fleming , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1542 Lines: 31 On Sun, Dec 12, 2010 at 1:52 PM, Chris Ball wrote: > Hi Will, > > On Sun, Dec 12, 2010 at 10:57:44AM +0000, Will Newton wrote: >> > drivers/mmc/host/dw_mmc.c: In function ?dw_mci_pull_data64?: >> > drivers/mmc/host/dw_mmc.c:998: error: implicit declaration of function ?__raw_readq? >> > >> > because arch/arm doesn't implement raw versions of these 64-bit accesses. >> > I'm surprised that this driver hasn't been compiled on ARM before! ?What >> >> That particular bit of code has been added since it was last built for >> arm. Our architecture can do 64bit accesses so we implement readq. >> Unfortunately there doesn't seem to be a sane way to conditionalize >> code for architectures that have or don't have readq, so I suspect >> I'll have to just remove that branch of the if statement for now. > > (Russell, thanks for the excellent explanation.) > > Other drivers (MTD, gpio/basic_mmio_gpio.c, fs/fuse, pcm_oss.c) > conditionalize uses of {read,write}q on BITS_PER_LONG >= 64, so > something like this: I don't think that's going to work, BITS_PER_LONG isn't equivalent to "can do 64bit IO accesses", at least it isn't on our architecture. x86 is in the same situation it would appear, although x86 does explicitly #define readq so it may be possible to #ifdef on that? -- 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/