linux-kernel - Re: [PATCH 1/1] edac x38: new MC driver module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Feb 2009 19:11:01 +0900
From:	Hitoshi Mitake <h.mitake@...il.com>
To:	"Hitoshi Mitake" <h.mitake@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "Sam Ravnborg" <sam@...nborg.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Geert Uytterhoeven" <geert@...ux-m68k.org>,
	"Luck, Tony" <tony.luck@...el.com>,
	"Russell King" <rmk+lkml@....linux.org.uk>,
	"Ralf Baechle" <ralf@...ux-mips.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Doug Thompson" <norsk5@...oo.com>, dougthompson@...ssion.com,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/1] edac x38: new MC driver module

On Tue, 2 Dec 2008 08:58:19 +0900
"Hitoshi Mitake" <h.mitake@...il.com> wrote:

> On Mon, Dec 1, 2008 at 22:59, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Hitoshi Mitake <h.mitake@...il.com> wrote:
> >
> >> On Mon, Dec 1, 2008 at 01:15, Ingo Molnar <mingo@...e.hu> wrote:
> >> >
> >> > * Hitoshi Mitake <h.mitake@...il.com> wrote:
> >> >
> >> >> On Sun, 30 Nov 2008 10:24:07 +0100
> >> >> Ingo Molnar <mingo@...e.hu> wrote:
> >> >>
> >> >> >
> >> >> > the 32-bit build broke promptly - readq/writeq is a family of APIs that
> >> >> > has to be either fully provided or not provided at all. The fix is below.
> >> >>
> >> >> Thanks for your fix and adding!
> >> >> When will this patch be added to mainline?
> >> >> I want to rewrite x38_edac.c to adapt new APIs.
> >> >
> >> > v2.6.29 at the earliest - if there are no regressions. A number of
> >> > drivers use these APIs and usage is a bit messy - so bugs could be
> >> > triggered, etc.
> >> >
> >> Thanks. What is URL of your repository?
> >> I want to look your tree and test it.
> >
> > you can pick up tip/master via:
> >
> >  http://people.redhat.com/mingo/tip.git/README
> >
> 
> Thanks!


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?
I paste a patch for x86 as sample. If I could find a good way,
I'll rewrite patches and send them to maintainers of each architectures.


Signed-off-by: Hitoshi Mitake <h.mitake@...il.com>

---
 arch/x86/Kconfig |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9c39095..d22f9a6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -19,8 +19,6 @@ config X86_64
 config X86
 	def_bool y
 	select HAVE_AOUT if X86_32
-	select HAVE_READQ
-	select HAVE_WRITEQ
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_IDE
 	select HAVE_OPROFILE
@@ -1980,6 +1978,25 @@ config HAVE_ATOMIC_IOMAP
 	def_bool y
 	depends on X86_32
 
+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.
+
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"
-- 
1.6.1.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/