From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 40B3Mg1N3lzF2Kd for ; Wed, 28 Mar 2018 21:02:22 +1100 (AEDT) Message-ID: <1522231287.21446.9.camel@kernel.crashing.org> Subject: Re: RFC on writel and writel_relaxed From: Benjamin Herrenschmidt To: Arnd Bergmann Cc: Will Deacon , Sinan Kaya , Jason Gunthorpe , David Laight , Oliver , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "linux-rdma@vger.kernel.org" , "Paul E. McKenney" , Peter Zijlstra , Ingo Molnar , Jonathan Corbet Date: Wed, 28 Mar 2018 21:01:27 +1100 In-Reply-To: References: <1522141019.7364.43.camel@kernel.crashing.org> <20180327095745.GB29373@arm.com> <20180327100944.GD29373@arm.com> <20180327110258.GF2464@arm.com> <20180327143628.GA10642@arm.com> <1522186185.7364.59.camel@kernel.crashing.org> <20180328085338.GA28871@arm.com> <1522230616.21446.1.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2018-03-28 at 11:55 +0200, Arnd Bergmann wrote: > > powerpc and ARM can't quite make them synchronous I think, but at least > > they should have the same semantics as writel. > > One thing that ARM does IIRC is that it only guarantees to order writel() within > one device, and the memory mapped PCI I/O space window almost certainly > counts as a separate device to the CPU. That sounds bogus. > In the absence of an enforced global synchronization during an I/O port > access, that means writel() and outb() can be reordered before they arrive > at a device in theory. Again, this rarely matters in practice, but I think it > makes sense to document the less strict behavior here, given that we have > common hardware that can't provide x86 compatible semantics. Can't you put some kind of super heavy handed barrier in inX/outX ? These things are never going to be performance sensitive anyway... Cheers, Ben.