From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755891AbZBVOQY (ORCPT ); Sun, 22 Feb 2009 09:16:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753805AbZBVOP4 (ORCPT ); Sun, 22 Feb 2009 09:15:56 -0500 Received: from ti-out-0910.google.com ([209.85.142.184]:22438 "EHLO ti-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753189AbZBVOPx (ORCPT ); Sun, 22 Feb 2009 09:15:53 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=VBBGDE1PYBGctC01fu36BYN+/ys5c3R128hp39g2oN3mO2FHFWdda6tD6UptjK8jCL d0WKFvbXCJ9hclt/vwPE4AQLmMECQ2jtc5g4sT3fnOPQ5GJijqcLInpHLz/j0DtwKV79 3uwUPxpYT870yBalCK3cPInICHfH8OFlUS1IU= Date: Sun, 22 Feb 2009 23:15:46 +0900 From: Hitoshi Mitake To: Sam Ravnborg , rth@twiddle.net Cc: Ingo Molnar , "H. Peter Anvin" , Geert Uytterhoeven , "Luck, Tony" , Russell King , Ralf Baechle , Andrew Morton , Doug Thompson , dougthompson@xmission.com, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH 1/1] edac x38: new MC driver module Message-Id: <20090222231546.5d84eafc.h.mitake@gmail.com> In-Reply-To: <20090221130937.GA31562@uranus.ravnborg.org> References: <20081129180144.GA15533@uranus.ravnborg.org> <20081130171604.dc3c8715.h.mitake@gmail.com> <20081130083700.GA31644@elte.hu> <20081130092407.GA10802@elte.hu> <20081201002056.d9f9204c.h.mitake@gmail.com> <20081130161504.GA25627@elte.hu> <20081201135922.GA30068@elte.hu> <20090221191101.62945118.h.mitake@gmail.com> <20090221130937.GA31562@uranus.ravnborg.org> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.12.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 21 Feb 2009 14:09:37 +0100 Sam Ravnborg wrote: > > Hi, > > > > Very sorry for long distance between my previous post and this... > > > > I wrote a patch to add HAVE_READQ and HAVE_WRITEQ to each architecture's Kconfig file > > which have readq() and writeq(). > > > > But there is problem. > > I wrote helps for HAVE_READQ and HAVE_WRITEQ in Kconfig file > > accodring to the advice by Russell King ( http://marc.info/?l=linux-kernel&m=122701161824218&w=2 ), > > but these helps are invisible when I doing menuconfig. > > (when type '/' and search readq string, HAVE_READQ found, but > > help string is not printed...) > > > > Do you have some nice technique that make these helps visible easily? > Thank you for your replying, Russell and Sam. > The options are not visible in menuconfig and therefore the is not > much point in displaying help for them thre when you search for the symbol. > But the help contained in the KConfig file is fully justified as it is > now documented why/when to select these options. > > Sam Hmm, so I try to send my patches to each maintainers of architectures. description of the patch: Adding HAVE_READQ, HAVE_WRITEQ and their help texts to each architecture's Kconfig file which have readq() and writeq(). Signed-off-by: Hitoshi Mitake --- arch/alpha/Kconfig | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 9fb8aae..ecca919 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -672,3 +672,20 @@ source "crypto/Kconfig" source "lib/Kconfig" +config HAVE_READQ + def_bool y + help + This is a sign to represent that this architecture provides + readq() function. readq() is a function to read 8 bytes from + I/O space. Each drivers use readq() must depend on this symbol. + Because lots of little private readq() implementations + all over the tree is sucks. + +config HAVE_WRITEQ + def_bool y + help + This is a sign to represent that this architecture provides + writeq() function. writeq() is a function to read 8 bytes from + I/O space. Each drivers use writeq() must depend on this symbol. + Because lots of little private writeq() implementations + all over the tree is sucks. -- 1.6.1.2