linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: jgarzik@pobox.com, linux-kernel@vger.kernel.org,
	netdev@oss.sgi.com, greg@kroah.com, akpm@osdl.org
Subject: Re: [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526
Date: Thu, 27 Jan 2005 15:31:14 -0800	[thread overview]
Message-ID: <20050127153114.72be03e2.davem@davemloft.net> (raw)
In-Reply-To: <20050127225725.F3036@flint.arm.linux.org.uk>

On Thu, 27 Jan 2005 22:57:25 +0000
Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> Has e100 actually been fixed to use the PCI DMA API correctly yet?

It seems to be doing the right thing.  I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing the chip really relies upon is ordering
of visibility and this is achieved via a combination of cpu memory
barriers and the correct DMA sync calls.

For example, a pci_dma_sync_single_for_cpu() is always performed before
peeking at the descriptors at RX interrupt time (see e100_rx_indicate).

When new descriptors are written to, then linked into the chain it
memory barriers the cpu writes then DMA syncs the previous descriptor
to the device.  This is occuring in e100_alloc_skb().

Therefore the only missing sync would be of the new RX descriptor
when linking things in like that, ie. at the end of e100_rx_alloc_skb()
if rx->prev->skb is non-NULL.

  reply	other threads:[~2005-01-28  0:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-27 20:45 [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526 Jeff Garzik
2005-01-27 21:07 ` Christoph Hellwig
2005-02-06 18:44   ` [2.6 patch] kill IPHASE5526 Adrian Bunk
2005-01-27 22:57 ` [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526 Russell King
2005-01-27 23:31   ` David S. Miller [this message]
2005-01-28  0:14     ` Russell King
2005-01-28  0:48       ` Lennert Buytenhek
2005-01-28  0:48       ` David S. Miller
2005-01-28  1:58         ` Scott Feldman
2005-01-28  5:22           ` David S. Miller
2005-01-28  9:33           ` [ANN] removal of certain net drivers coming soon: eepro100,?xircom_tulip_cb, iph5526 Meelis Roos
2005-01-28 19:11             ` Scott Feldman
2005-02-01 12:48               ` Meelis Roos
2005-02-01 18:57                 ` Scott Feldman
2005-02-01 19:09                   ` linux-os
2005-02-01 19:28                     ` Scott Feldman
2005-01-29  8:17 ` [ANN] removal of certain net drivers coming soon: eepro100, xircom_tulip_cb, iph5526 Greg KH

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=20050127153114.72be03e2.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).