From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756647AbZDTQDv (ORCPT ); Mon, 20 Apr 2009 12:03:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755940AbZDTQDm (ORCPT ); Mon, 20 Apr 2009 12:03:42 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:52174 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754890AbZDTQDm (ORCPT ); Mon, 20 Apr 2009 12:03:42 -0400 Date: Mon, 20 Apr 2009 18:03:32 +0200 From: Ingo Molnar To: Hitoshi Mitake Cc: "H. Peter Anvin" , Roland Dreier , Thomas Gleixner , "Robert P. J. Day" , Linux Kernel Mailing List Subject: Re: arch/x86/Kconfig selects invalid HAVE_READQ, HAVE_WRITEQ vars Message-ID: <20090420160332.GB9689@elte.hu> References: <20090419214602.GA21527@elte.hu> <49EBCDC0.1020001@zytor.com> <20090420105304.GC6670@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Hitoshi Mitake wrote: > On Mon, Apr 20, 2009 at 19:53, Ingo Molnar wrote: > > > > * H. Peter Anvin wrote: > > > >> 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. > > > > Yeah - with the default being the natural low-high order. > > > > The other argument is that if a driver really wants some rare, oddly > > different order it should better define its own method that is not > > named in the same (or in a similar) way as an existing generic API. > > Otherwise, confusion will ensue. > I think this is a good way. > readq/writeq are already in Linus's tree, removing these is not a good idea. > > And I've sent the patch to fix a little problem of Kconfig about > readq/writeq to you. > http://marc.info/?l=linux-kernel&m=123521109218008&w=2 > Did you notice? > > Adding cautions about accessing order or non-atomic to Kconfig's help > part may be benefit. It's better to add add such non-interactive help text as Makefile comments: # # This option ... # and they should be invisible in make menuconfig. This is a facility provided by architectures. Note, the whole patchset is still incomplete - readq/writeq wrappers should be provided on all 32-bit architectures. Are those in the works? Ingo