From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bagnes.atmel.com (smtpeu1.atmel.com [195.65.72.27]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id C475FDDEF4 for ; Mon, 2 Jun 2008 18:18:53 +1000 (EST) Date: Mon, 2 Jun 2008 10:11:02 +0200 From: Haavard Skinnemoen To: Geert Uytterhoeven Subject: Re: MMIO and gcc re-ordering issue Message-ID: <20080602101102.0d8979c5@hskinnemo-gx745.norway.atmel.com> In-Reply-To: References: <1211852026.3286.36.camel@pasglop> <20080526.184047.88207142.davem@davemloft.net> <1211854540.3286.42.camel@pasglop> <20080526.192812.184590464.davem@davemloft.net> <1211859542.3286.46.camel@pasglop> <1211922621.3286.80.camel@pasglop> <1211924335.3286.89.camel@pasglop> <20080527214241.GA22636@parisc-linux.org> <1211926636.3286.100.camel@pasglop> <20080528103648.54eb8734@hskinnemo-gx745.norway.atmel.com> <1212110003.15633.0.camel@pasglop> <20080530080700.773a82cc@siona.local> <1212132267.15633.69.camel@pasglop> <20080530102706.56fca248@siona.local> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: linux-arch@vger.kernel.org, Matthew Wilcox , linux-kernel@vger.kernel.org, David Miller , linuxppc-dev@ozlabs.org, tpiepho@freescale.com, scottwood@freescale.com, Torvalds , Linus, alan@lxorguk.ukuu.org.uk List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Geert Uytterhoeven wrote: > On Fri, 30 May 2008, Haavard Skinnemoen wrote: > > Maybe we need another interface that does not do byteswapping but > > provides stronger ordering guarantees? > > The byte swapping depends on the device/bus. Of course. But isn't it reasonable to assume that a device integrated on the same silicon as the CPU is connected to a somewhat sane bus which doesn't require any byte swapping? > So what happened to the old idea of putting the accessor function pointers > in the device/bus structure? Don't know. I think it sounds like overkill to replace a simple load or store with an indirect function call. Haavard