From patchwork Wed Sep 19 13:35:47 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 1477671 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by patchwork2.kernel.org (Postfix) with ESMTP id 3FD3CDF280 for ; Wed, 19 Sep 2012 13:37:52 +0000 (UTC) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TEKRk-0000P2-PI; Wed, 19 Sep 2012 13:36:08 +0000 Received: from moutng.kundenserver.de ([212.227.17.10]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TEKRh-0000OT-5i for linux-arm-kernel@lists.infradead.org; Wed, 19 Sep 2012 13:36:06 +0000 Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com [195.212.29.180]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MPt2M-1TAUgW3VJK-004Peb; Wed, 19 Sep 2012 15:35:51 +0200 From: Arnd Bergmann To: Tony Lindgren Subject: Re: [PATCH 17/24] ARM: OMAP: use __iomem pointers for MMIO Date: Wed, 19 Sep 2012 13:35:47 +0000 User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; ) References: <1347658492-11608-1-git-send-email-arnd@arndb.de> <20120916203850.GI4521@atomide.com> <20120917212506.GB11762@atomide.com> In-Reply-To: <20120917212506.GB11762@atomide.com> MIME-Version: 1.0 Message-Id: <201209191335.48051.arnd@arndb.de> X-Provags-ID: V02:K0:plMAfJfxDvN8p5Sgy+7RI+3xno0BSG9gLLBrj404S+w 9M2QaRyBnP3NbzVKxSqxHPtKRATkbOMpckYqsvfYSjfilaKttW Tt25fnYBEY1zfERk919dPrgGXnZkpgDf8+G2mpxu/mmMhSX+5I W0eeCGT3eXQozAlERZDKOxovoAKMQ3nJToNW7QoBXDhF4rTKB6 YCm6Zvk1GrlI2/aKT2gI7JELsRpaIltVORaXj+QwuQysK8DXv7 SFTIcD7Ukye/wY8MUwT1KOGgNlNW10DkK5D6k7+4eyu/17uKV+ tLsAsdOEAwNYxxbPASj8lxCJ1TuZMWTyhE4QgYvN2puL58duuW z149tlC2xvI9tPeAHaaY= X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.10 listed in list.dnswl.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Nicolas Pitre , Lokesh Vutla , Will Deacon , linux-kernel@vger.kernel.org, sricharan , Santosh Shilimkar , Russell King , Felipe Balbi , Shubhrajyoti D , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org On Monday 17 September 2012, Tony Lindgren wrote: > * Tony Lindgren [120916 13:39]: > > * Arnd Bergmann [120915 13:15]: > > > On Saturday 15 September 2012, Tony Lindgren wrote: > > > > With my patches, this is now all omap1 specific and > > > > moved to arch/arm/mach-omap1/include/mach/hardware.h. > > > > It's probably easiest to just update this patch on > > > > top of the hardware.h changes I've done. > > > > > > Yes, sounds good. Do you want to send a patch for that > > > and let me drop this one then? > > > > Yes I can pick this one and update it against one of my > > branches to avoid merge conflicts. > > This applies against mach-omap1/include/mach/hardware.h > with some fuzz so no issues there. > > But I think we should not apply it as these are physical > addresses, not virtual addresses for omap1. Right, I misread what is actually going on here because the only driver I looked at treated the address as a virtual address pointer. > We have IOMEM already in use for omap_read/write because of: > > #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET) > > I think the right solution is to eventually get rid of > omap_read/write for omap1 also and replace them with ioremap > + readl/writel. Agreed. > Or am I missing something? I did not see any new warnings for omap1, but I did see this on omap2plus_defconfig: drivers/watchdog/omap_wdt.c: In function 'omap_wdt_ioctl': drivers/watchdog/omap_wdt.c:222:4: error: passing argument 1 of '__raw_readw' makes pointer from integer without a cast [-Werror] arch/arm/include/asm/io.h:71:90: note: expected 'const volatile void *' but argument is of type 'unsigned int' It seems I misinterpreted this, and it's actually a bug in the watchdog driver that should be fixed using this patch instead (and backport it to stable) This bug seems to have been introduced in 2008 by 9f69e3b0c "[WATCHDOG] omap_wdt.c: another ioremap() fix" without anyone ever noticing and now got caught. Of course it should be replaced by something better when omap_read/write is finally getting removed. I'll drop my omap patch for now, because it's obviously wrong, and let you guys figure out what to do about the watchdog driver. Arnd diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index fceec4f..7b45802 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -218,9 +218,11 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd, case WDIOC_GETSTATUS: return put_user(0, (int __user *)arg); case WDIOC_GETBOOTSTATUS: +#ifdef CONFIG_ARCH_OMAP1 if (cpu_is_omap16xx()) - return put_user(__raw_readw(ARM_SYSST), + return put_user(omap_readw(ARM_SYSST), (int __user *)arg); +#endif if (cpu_is_omap24xx()) return put_user(omap_prcm_get_reset_sources(), (int __user *)arg);