From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [81.2.110.250] ([81.2.110.250]:6889 "EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP id S932242AbWCGT2j (ORCPT ); Tue, 7 Mar 2006 14:28:39 -0500 Subject: Re: [PATCH] Document Linux's memory barriers From: Alan Cox In-Reply-To: References: <31492.1141753245@warthog.cambridge.redhat.com> <1141756825.31814.75.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 07 Mar 2006 19:33:41 +0000 Message-Id: <1141760021.2455.1.camel@localhost.localdomain> Mime-Version: 1.0 Sender: linux-arch-owner@vger.kernel.org To: "linux-os (Dick Johnson)" Cc: David Howells , torvalds@osdl.org, akpm@osdl.org, mingo@redhat.com, linux-arch@vger.kernel.org, linuxppc64-dev@ozlabs.org, Linux kernel List-ID: On Maw, 2006-03-07 at 13:54 -0500, linux-os (Dick Johnson) wrote: > On Tue, 7 Mar 2006, Alan Cox wrote: > > writel(STOP_DMA, &foodev->ctrl); > > free_dma_buffers(foodev); > > > > This leads to horrible disasters. > > This might be a good place to document: > dummy = readl(&foodev->ctrl); Absolutely. And this falls outside of the memory barrier functions. > > Will flush all pending writes to the PCI bus and that: > (void) readl(&foodev->ctrl); > ... won't because `gcc` may optimize it away. In fact, variable > "dummy" should be global or `gcc` may make it go away as well. If they were ordinary functions then maybe, but they are not so a simple readl(&foodev->ctrl) will be sufficient and isn't optimised away. Alan