All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: Andrew Morton <akpm@osdl.org>
Cc: "Bryan O'Sullivan" <bos@pathscale.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1 of 3] Introduce __raw_memcpy_toio32
Date: Tue, 10 Jan 2006 06:55:17 -0800	[thread overview]
Message-ID: <adaslrw3zfu.fsf@cisco.com> (raw)
In-Reply-To: <20060110011844.7a4a1f90.akpm@osdl.org> (Andrew Morton's message of "Tue, 10 Jan 2006 01:18:44 -0800")

    Bryan> This arch-independent routine copies data to a
    Bryan> memory-mapped I/O region, using 32-bit accesses.  It does
    Bryan> not guarantee access ordering, nor does it perform a memory
    Bryan> barrier afterwards.  This style of access is required by
    Bryan> some devices.

    Andrew> Not providing orderingor barriers makes this a rather
    Andrew> risky thing to export - people might use it, find their
    Andrew> driver "works" on one architecture, but fails on another.

    Andrew> I guess the "__" is a decent warning of this, and the
    Andrew> patch anticipates a higher-level raw_memcpy_toio32() which
    Andrew> implements those things, yes?

I suggested the __raw_ name to parallel __raw_writel and friends.  The
name for the version that ends with a write barrier would presumably
be just "memcpy_toio32()".  Bryan could easily add that his patch as
well, even though the Pathscale driver will only use the __raw_ version.

    Andrew> How come __raw_memcpy_toio32() is inlined?

That is a good question, especially since the optimized
x86_64-specific version is out-of-line.  I suspect the answer is
mainly that that's the easiest way to stick it in a header in
include/asm-generic.  I think it would be worth working a little
harder and making the generic version out-of-line.

  reply	other threads:[~2006-01-10 14:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-06 20:26 [PATCH 0 of 3] 32-bit MMIO copy routine Bryan O'Sullivan
2006-01-06 20:26 ` [PATCH 1 of 3] Introduce __raw_memcpy_toio32 Bryan O'Sullivan
2006-01-10  9:18   ` Andrew Morton
2006-01-10 14:55     ` Roland Dreier [this message]
2006-01-10 16:07       ` Bryan O'Sullivan
2006-01-10 16:56         ` [PATCH] [RFC] Generic 32-bit MMIO copy, out of line Bryan O'Sullivan
2006-01-10 17:07         ` [PATCH 1 of 3] Introduce __raw_memcpy_toio32 Christoph Hellwig
2006-01-10 17:13           ` Bryan O'Sullivan
2006-01-10 17:49           ` Bryan O'Sullivan
2006-01-10 17:51             ` Christoph Hellwig
2006-01-10 17:55               ` Bryan O'Sullivan
2006-01-10 22:05                 ` Andrew Morton
2006-01-10 22:29                   ` Bryan O'Sullivan
2006-01-10 23:32                     ` Andrew Morton
2006-01-11 17:20                       ` Bryan O'Sullivan
2006-01-11 17:22                         ` Sam Ravnborg
2006-01-11 17:30                           ` Andrew Morton
2006-01-11 17:43                             ` Bryan O'Sullivan
2006-01-11 18:49                               ` Roland Dreier
2006-01-11 18:57                                 ` Bryan O'Sullivan
2006-01-11 19:01                                   ` Roland Dreier
2006-01-11 19:08                                     ` Bryan O'Sullivan
2006-01-13 15:19                       ` Adrian Bunk
2006-01-10 18:02               ` Randy.Dunlap
2006-01-10 20:04         ` Sam Ravnborg
2006-01-10 15:59     ` Bryan O'Sullivan
2006-01-06 20:26 ` [PATCH 2 of 3] memcpy32 for x86_64 Bryan O'Sullivan
2006-01-06 20:26 ` [PATCH 3 of 3] Add __raw_memcpy_toio32 to each arch Bryan O'Sullivan
  -- strict thread matches above, loose matches on Subject: below --
2006-01-10 19:53 [PATCH 0 of 3] 32-bit MMIO copy routines, reworked Bryan O'Sullivan
2006-01-10 19:53 ` [PATCH 1 of 3] Introduce __raw_memcpy_toio32 Bryan O'Sullivan
2006-01-11 22:39 [PATCH 0 of 3] MMIO 32-bit copy routine, the final frontier Bryan O'Sullivan
2006-01-11 22:39 ` [PATCH 1 of 3] Introduce __raw_memcpy_toio32 Bryan O'Sullivan
2006-01-11 23:43   ` Andrew Morton
     [not found] <5s6p8-1O3-29@gated-at.bofh.it>
     [not found] ` <5s6p8-1O3-27@gated-at.bofh.it>
     [not found]   ` <5tnZx-1lb-17@gated-at.bofh.it>
     [not found]     ` <5tt8U-xV-5@gated-at.bofh.it>
     [not found]       ` <5tueu-2mb-9@gated-at.bofh.it>
     [not found]         ` <5tvaH-3MA-55@gated-at.bofh.it>
     [not found]           ` <5tvX6-4MO-13@gated-at.bofh.it>
     [not found]             ` <5tvX6-4MO-11@gated-at.bofh.it>
     [not found]               ` <5tvXa-4MO-23@gated-at.bofh.it>
     [not found]                 ` <5tzQR-2zH-11@gated-at.bofh.it>
2006-01-15 15:33                   ` Bodo Eggert

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=adaslrw3zfu.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=akpm@osdl.org \
    --cc=bos@pathscale.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.