All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hitoshi Mitake <h.mitake@gmail.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hitoshi Mitake <mitake@clustcom.com>,
	Doug Thompson <norsk5@yahoo.com>,
	dougthompson@xmission.com, linux-kernel@vger.kernel.org,
	ktaka@clustcom.com, linux-arch@vger.kernel.org
Subject: Re: [PATCH 1/1] edac x38: new MC driver module
Date: Fri, 14 Nov 2008 00:15:14 +0900	[thread overview]
Message-ID: <20081114001514.ea469b4f.h.mitake@gmail.com> (raw)
In-Reply-To: <20081111061140.GB32733@linux-sh.org>

On Tue, 11 Nov 2008 15:11:40 +0900
Paul Mundt <lethal@linux-sh.org> wrote:

> On Sun, Nov 09, 2008 at 11:26:46AM -0800, Andrew Morton wrote:
> > (cc linux-arch)
> > 
> > > It seems that architectures that provide readq/writeq are
> > > mips, parisc and x86 (and x86_64).
> > > 
> There are more than that, grep arch/*/include also.
> 
> In addition to mips, parisc, and x86, there is ia64, alpha, sh, and
> sparc.

I didn't noticed these functions, thanks.

> 
> > #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.
> > 
> However this is handled, we don't want a rehash of the read/writes{b,w,l} fiasco.
> 
> Allowing drivers to do their own local implementations of these things
> has always been a complete disaster. A Kconfig option will at least take
> care of having these craptastic ifdef lists for architectures in every
> driver that rolls its own implementation.
> 
> Even a sub-optimal asm-generic version would be preferable, if the
> semantics are well enough defined and consistently adhered to.

I found nice source file, lib/iomap.c.
There are architecture independent read/write{b,w,l} (named like ioread8).

I want to implement architecture independent readq/writeq in lib/iomap.c .
Andrew told,

> 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.

But I want to use x38_edac.c on x86_32 environment,
and I think similar desire may occur in the future.

Is this way good enough? Request for comment.

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

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17 21:39 [PATCH 1/1] edac x38: new MC driver module 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2008-11-29  0:56 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
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

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=20081114001514.ea469b4f.h.mitake@gmail.com \
    --to=h.mitake@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dougthompson@xmission.com \
    --cc=ktaka@clustcom.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mitake@clustcom.com \
    --cc=norsk5@yahoo.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.