From: Richard Hirst <rhirst@linuxcare.com>
To: "David S. Miller" <davem@redhat.com>
Cc: matthew@wil.cx, grundler@cup.hp.com,
parisc-linux@thepuffingroup.com, jgarzik@mandrakesoft.com
Subject: Re: [parisc-linux] tulip DMA mapping
Date: Fri, 10 Nov 2000 11:12:20 +0000 [thread overview]
Message-ID: <20001110111220.J32715@linuxcare.com> (raw)
In-Reply-To: <200011101016.CAA12058@pizda.ninka.net>; from davem@redhat.com on Fri, Nov 10, 2000 at 02:16:11AM -0800
I've quoted the whole of Grants message below, so you can see the
context. It looks like tulip is treating zero as meaning it
doesn't have anything to pci_unmap...
Grant Grundler wrote:
> Hi all,
> I see a "bug" in tulip's usage of mapping services.
> It's not the bug I was looking for unfortunately.
>
> In line 217 of drivers/net/tulip/interrupt.c:
>
> if (tp->tx_buffers[entry].mapping)
> pci_unmap_single(tp->pdev,
> tp->tx_buffers[entry].mapping,
> sizeof(tp->setup_frame),
> PCI_DMA_TODEVICE);
>
> 0 is a valid pci_map_single() return value when the system has an IO MMU.
>
> The system will panic before pci_map_single() will fail.
> The driver needs to remember some other way if a buffer was mapped or not.
> Or the Documentation/DMA-mapping.txt should be changed - ie add this
> to the interface definition and I can reserve the 1st mapping
> entry so no-one uses it.
Richard
On Fri, Nov 10, 2000 at 02:16:11AM -0800, David S. Miller wrote:
> Date: Fri, 10 Nov 2000 10:18:08 +0000
> From: Matthew Wilcox <matthew@wil.cx>
>
> > Should I be mailing Jeff Garzik <jgarzik@mandrakesoft.com> directly?
> > Or can someone who knows Jeff point this out to him?
>
> i've cc'd jeff & dave miller on this.
>
> In 2.4.x there is _NO_ error return from the PCI dma functions except
> the consistent DMA mapping ones.
>
> This was an explicit design decision, the dynamic mapping functions
> should never fail, and if they do it is a hard error.
>
> Therefore no drivers need to check for failure, as far as they are
> concerned, there is no failure.
>
> So what is the issue? In 2.5.x I'll add an error return facility
> (BTW: -1 ie. 0xfffffff would probably work as an error value on all
> platforms :-)
>
> Later,
> David S. Miller
> davem@redhat.com
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
>
>
next prev parent reply other threads:[~2000-11-10 11:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-09 20:12 [parisc-linux] tulip DMA mapping Grant Grundler
2000-11-10 10:18 ` Matthew Wilcox
2000-11-10 10:16 ` David S. Miller
2000-11-10 11:12 ` Richard Hirst [this message]
2000-11-10 11:26 ` David S. Miller
2000-11-10 14:30 ` Jeff Garzik
2001-03-04 17:22 ` Jeff Garzik
2000-11-10 16:29 ` Grant Grundler
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=20001110111220.J32715@linuxcare.com \
--to=rhirst@linuxcare.com \
--cc=davem@redhat.com \
--cc=grundler@cup.hp.com \
--cc=jgarzik@mandrakesoft.com \
--cc=matthew@wil.cx \
--cc=parisc-linux@thepuffingroup.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.