From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753401AbZDTBU7 (ORCPT ); Sun, 19 Apr 2009 21:20:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753104AbZDTBUt (ORCPT ); Sun, 19 Apr 2009 21:20:49 -0400 Received: from terminus.zytor.com ([198.137.202.10]:49902 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753053AbZDTBUs (ORCPT ); Sun, 19 Apr 2009 21:20:48 -0400 Message-ID: <49EBCDC0.1020001@zytor.com> Date: Sun, 19 Apr 2009 18:20:00 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Roland Dreier CC: Ingo Molnar , Thomas Gleixner , "Robert P. J. Day" , Hitoshi Mitake , Linux Kernel Mailing List Subject: Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars References: <20090419214602.GA21527@elte.hu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Roland Dreier wrote: > > Notice that it reads from addr+4 *before* it reads from addr, rather > than after as in your example (and in fact your example depends on > undefined compiler semantics, since there is no sequence point between > the two operands of the | operator). Now, I don't know that hardware, > so I don't know if it makes a difference, but the niu example I gave in > my original email shows that given hardware with clear-on-read > registers, the order does very much matter. > At least for x86, the order should be low-high, because that is the order that those two transactions would be seen on a 32-bit bus downstream from the CPU if the CPU issued a 64-bit transaction. The only sane way to handle this as something other than per-driver hacks would be something like: #include /* Any 64-bit I/O OK */ #include /* Low-high splitting OK */ #include /* High-low splitting OK */ #include /* 64-bit I/O must be atomic */ ... i.e. letting the driver choose what fallback method it will accept. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.