All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hitoshi Mitake <h.mitake@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	"Luck, Tony" <tony.luck@intel.com>,
	Russell King <rmk+lkml@arm.linux.org.uk>,
	Ralf Baechle <ralf@linux-mips.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Doug Thompson <norsk5@yahoo.com>,
	dougthompson@xmission.com, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH 1/1] edac x38: new MC driver module
Date: Sat, 29 Nov 2008 22:24:49 +0900	[thread overview]
Message-ID: <20081129222449.e341f028.h.mitake@gmail.com> (raw)
In-Reply-To: <20081129105229.GA9643@uranus.ravnborg.org>

On Sat, 29 Nov 2008 11:52:29 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:

> > 
> > But this is old way. ARCH_HAS_READQ and ARCH_HAS_WRITEQ are new ways
> > to determine existence of readq/writeq. Drivers which use readq/writeq should
> > depend on these values in their Kconfig file.
> 
> If we look at arch/x86/Kconfig we see:
> ### Arch settings
> config X86
>         def_bool y
>         select HAVE_AOUT if X86_32
>         select HAVE_UNSTABLE_SCHED_CLOCK
>         select HAVE_IDE
>         select HAVE_OPROFILE
>         select HAVE_IOREMAP_PROT
>         select HAVE_KPROBES
>         select ARCH_WANT_OPTIONAL_GPIOLIB
> 	...
> 
> So the normal syntax here is "HAVE_XXX_XXX" - not ARCH_HAS_XXX_XXX
> 
> If you update your patch please use this syntax,
> and locate the select under X86 - not under the 32/64 entries.

Thanks for your notification. I didn't notice that syntax rule.

> 
> But I do not see why adding these in the first place.
> 

Andrew Morton told that drivers which need readq/writeq should use ones of kernel,
and if architecture part of kernel does not provide readq/writeq, drivers should be disabled.

This is Andrew's mail:
http://marc.info/?l=linux-kernel&m=122625885124798&w=2
===> Quote:

#ifdef readq

Is a suitable way of determining whether the architecture implements
readq and writeq.  It isn't pretty, but it will suffice.

A problem with it is that drivers will then do

#ifndef readq
<provide a local implementation here>
#endif

which rather sucks - we don't want lots of little private readq/writeq
implementations all over the tree.

Perhaps it would be better to have a CONFIG_ARCH_HAS_READQ and to then
disable these drivers on the architectures which don't provide
readq/writeq support.

<====

This is new patch.

description of this patch
Adding implementation of readq/writeq to x86_32,
and adding config value to x86 architecture to determine existence of readq/writeq

Signed-off-by: Hitoshi Mitake <h.mitake@gmail.com>
---
 arch/x86/Kconfig          |    2 ++
 arch/x86/include/asm/io.h |   24 ++++++++++++++++++++++++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ac22bb7..75408fe 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -34,6 +34,8 @@ config X86
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_GENERIC_DMA_COHERENT if X86_32
 	select HAVE_EFFICIENT_UNALIGNED_ACCESS
+	select HAVE_READQ
+	select HAVE_WRITEQ
 
 config ARCH_DEFCONFIG
 	string
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index ac2abc8..ddc67aa 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -4,6 +4,7 @@
 #define ARCH_HAS_IOREMAP_WC
 
 #include <linux/compiler.h>
+#include <asm-generic/int-ll64.h>
 
 #define build_mmio_read(name, size, type, reg, barrier) \
 static inline type name(const volatile void __iomem *addr) \
@@ -57,6 +58,29 @@ build_mmio_write(__writeq, "q", unsigned long, "r", )
 /* Let people know we have them */
 #define readq readq
 #define writeq writeq
+
+#else  /* CONFIG_X86_32 from here */
+
+static inline __u64 readq(const volatile void __iomem *addr)
+{
+	const volatile u32 __iomem *p = addr;
+	u32 l, h;
+
+	l = readl(p);
+	h = readl(p+1);
+
+	return l + ((u64)h << 32);
+}
+
+static inline void writeq(__u64 val, volatile void __iomem *addr)
+{
+	writel(val, addr);
+	writel(val >> 32, addr+4);
+}
+
+#define readq readq
+#define writeq writeq
+
 #endif
 
 extern int iommu_bio_merge;
-- 
1.5.6.5

  reply	other threads:[~2008-11-29 13:24 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-29  0:56 [PATCH 1/1] edac x38: new MC driver module H. Peter Anvin
2008-11-29  0:56 ` H. Peter Anvin
2008-11-29  7:47 ` Hitoshi Mitake
2008-11-29  7:47   ` Hitoshi Mitake
2008-11-29  9:38   ` Ingo Molnar
2008-11-29 10:26     ` Hitoshi Mitake
2008-11-29 10:52       ` Sam Ravnborg
2008-11-29 13:24         ` Hitoshi Mitake [this message]
2008-11-29 18:01           ` Sam Ravnborg
2008-11-30  8:16             ` Hitoshi Mitake
2008-11-30  8:37               ` Ingo Molnar
2008-11-30  8:37                 ` Ingo Molnar
2008-11-30  9:24                 ` Ingo Molnar
2008-11-30  9:24                   ` Ingo Molnar
2008-11-30 15:20                   ` Hitoshi Mitake
2008-11-30 16:15                     ` Ingo Molnar
2008-12-01 13:51                       ` Hitoshi Mitake
2008-12-01 13:59                         ` Ingo Molnar
2008-12-01 23:58                           ` Hitoshi Mitake
2008-12-04 15:58                             ` Hitoshi Mitake
2009-01-16  1:24                               ` Hitoshi Mitake
2009-02-21 10:11                             ` Hitoshi Mitake
2009-02-21 10:39                               ` Russell King
2009-02-21 13:09                               ` Sam Ravnborg
2009-02-22 14:15                                 ` Hitoshi Mitake
2009-02-22 14:16                                 ` Hitoshi Mitake
2009-02-22 14:16                                   ` Hitoshi Mitake
2009-02-22 14:16                                   ` Hitoshi Mitake
2009-02-22 14:18                                 ` Hitoshi Mitake
2009-02-22 14:18                                   ` Hitoshi Mitake
2009-02-22 14:18                                   ` Hitoshi Mitake
2009-02-22 14:19                                 ` Hitoshi Mitake
2009-02-22 14:20                                 ` Hitoshi Mitake
2009-02-22 14:21                                 ` Hitoshi Mitake
  -- strict thread matches above, loose matches on Subject: below --
2008-10-17 21:39 dougthompson
2008-10-20 23:32 ` Andrew Morton
2008-11-05 22:29   ` Hitoshi Mitake
2008-11-05 16:26     ` Doug Thompson
2008-11-07  0:46       ` Andrew Morton
2008-11-07 15:28         ` Hitoshi Mitake
2008-11-07  6:31           ` Andrew Morton
2008-11-07 15:38             ` Hitoshi Mitake
2008-11-07  7:11               ` Andrew Morton
2008-11-09 15:10                 ` Hitoshi Mitake
2008-11-09 19:26                   ` Andrew Morton
2008-11-11  6:11                     ` Paul Mundt
2008-11-13 15:15                       ` Hitoshi Mitake
2008-11-18 12:16                     ` Ralf Baechle
2008-11-18 12:32                       ` Russell King
2008-11-20 16:19                         ` Hitoshi Mitake
2008-11-23 23:52                           ` H. Peter Anvin
2008-11-24 17:18                             ` Luck, Tony
2008-11-24 17:18                               ` Luck, Tony
2008-11-24 18:02                               ` H. Peter Anvin
2008-11-25  2:55                                 ` Hitoshi Mitake
2008-11-25  5:13                                   ` H. Peter Anvin
2008-11-25 15:30                                     ` Hitoshi Mitake
2008-11-25 15:46                                       ` Geert Uytterhoeven
2008-11-25 16:10                                         ` Hitoshi Mitake
2008-11-29  0:11                                           ` Hitoshi Mitake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081129222449.e341f028.h.mitake@gmail.com \
    --to=h.mitake@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dougthompson@xmission.com \
    --cc=geert@linux-m68k.org \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=norsk5@yahoo.com \
    --cc=ralf@linux-mips.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=sam@ravnborg.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.