From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 May 2001 03:09:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 May 2001 03:09:27 -0400 Received: from pizda.ninka.net ([216.101.162.242]:28556 "EHLO pizda.ninka.net") by vger.kernel.org with ESMTP id ; Thu, 3 May 2001 03:09:11 -0400 From: "David S. Miller" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.979.650927.634060@pizda.ninka.net> Date: Thu, 3 May 2001 00:08:03 -0700 (PDT) To: Geert Uytterhoeven Cc: Linux Kernel Development Subject: Re: unsigned long ioremap()? In-Reply-To: In-Reply-To: X-Mailer: VM 6.75 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Geert Uytterhoeven writes: > Since you're not allowed to use direct memory dereferencing on ioremapped > areas, wouldn't it be more logical to let ioremap() return an unsigned long > instead of a void *? > > Of course we then have to change readb() and friends to take a long as well, > but at least we'd get compiler warnings when someone tries to do a direct > dereference. There is a school of thought which believes that: struct xdev_regs { u32 reg1; u32 reg2; }; val = readl(®s->reg2); is cleaner than: #define REG1 0x00 #define REG2 0x04 val = readl(regs + REG2); I'm personally ambivalent and believe that both cases should be allowed. BTW, current {read,write}{b,w,l}() allow both pointer and unsigned long arguments. If your implementation isn't casting the port address arg right now, perhaps you haven't tried to compile very many drivers which use these interfaces or you're just ignoreing the warnings :-) Later, David S. Miller davem@redhat.com