From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from caramon.arm.linux.org.uk ([212.18.232.186]:44042 "EHLO caramon.arm.linux.org.uk") by vger.kernel.org with ESMTP id S267382AbUIOUVG (ORCPT ); Wed, 15 Sep 2004 16:21:06 -0400 Date: Wed, 15 Sep 2004 21:20:56 +0100 From: Russell King Subject: Re: RFC: being more anal about iospace accesses.. Message-ID: <20040915212056.C31396@flint.arm.linux.org.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from torvalds@osdl.org on Wed, Sep 15, 2004 at 12:16:35PM -0700 Sender: Russell King To: Linus Torvalds Cc: Geert Uytterhoeven , Linux Arch list , Al Viro , Andrew Morton , Alan Cox , "David S. Miller" , Jeff Garzik List-ID: On Wed, Sep 15, 2004 at 12:16:35PM -0700, Linus Torvalds wrote: > On Wed, 15 Sep 2004, Geert Uytterhoeven wrote: > > Before people really start using this: what's the advantage of this scheme > > compared to e.g. dev->busops->in8(), which some of us have been waiting for > > since a long time? > > Ehh, exactly why would you wait for that? > > What this new interface is doing is to slowlt move "ioremap()" users over > to "pci_iomap()" (and by extension, maybe "sbus_ioremap()" etc if somebody > ever starts doing that too), which allows you to do the bus- and device- > specific translation just _once_. What about (PCI!) bus types where you need to write one register with the address and one with the data. (I'm glaring at a certain embedded CPU produced by a well known large chip manufacturer, which I think we need to do these games to get byte accesses to work correctly.) Sometimes unified accessor macros/functions just don't work. > In other words, I hereby proclaim that anybody who does "dev->busops" is a > total idiot. Good, I'll pass that comment on to other people and maybe we can force certain sillycon manufacturers to stop selling broken hardware. Or maybe the universe will implode. I think the latter is a more likely scenario than the former. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core