linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: "David S. Miller" <davem@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	jes@wildopensource.com, zaitcev@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: kills consistent_dma_mask
Date: 19 Aug 2003 22:31:36 +0200	[thread overview]
Message-ID: <m34r0dwfrr.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <20030819095547.2bf549e3.davem@redhat.com>

"David S. Miller" <davem@redhat.com> writes:

> (d) Makes implementations have to verify the mask is usable
> on every mapping attempt.

No, unless we have hardware which can return success on first mask check
then result error on subsequent mapping request.

We need to decide, though, as I'm going to fix it that way or another:

1) provide the mask argument to actual mapping requests (pci_map_*,
   pci_alloc_*, DMA API) and drop pci_dev->*dma_mask, or

2) add coherent_dma_mask pointer to struct driver as with normal mask,
   pointing to pci_dev->consistent_dma_mask

1: non-trivial, but IMHO makes things more clean and natural (from both
   system's and driver's view), and fits all special cases.


BTW: Why do we have this pointer (I mean u64 *dma_mask) in struct device?
Does it always point to pci_dev->dma_mask (and to similar value on EISA
etc)? I see some code checks for struct device->dma_mask=NULL, is it only
a safety check or does NULL have some meaning there?

Would it make sense to drop the masks in pci_dev and use (u64 not
pointers) *dma_masks in struct device? If so, would 0 there have the same
meaning as now NULL?
-- 
Krzysztof Halasa
Network Administrator

  parent reply	other threads:[~2003-08-19 20:37 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-17 22:34 [PATCH] RFC: kills consistent_dma_mask Krzysztof Halasa
2003-08-18  6:37 ` David S. Miller
2003-08-18 12:44   ` Krzysztof Halasa
2003-08-18 12:43     ` David S. Miller
2003-08-18 15:54       ` Krzysztof Halasa
2003-08-18 16:49         ` David S. Miller
2003-08-18 18:21           ` Krzysztof Halasa
2003-08-18 18:50             ` David S. Miller
2003-08-18 21:58               ` Krzysztof Halasa
2003-08-19  9:24                 ` Jes Sorensen
2003-08-19  9:21         ` Jes Sorensen
2003-08-18 13:00     ` Jes Sorensen
2003-08-18  8:07 ` Christoph Hellwig
2003-08-18 15:15 ` Pete Zaitcev
2003-08-18 16:14   ` Krzysztof Halasa
2003-08-19  9:16     ` Jes Sorensen
2003-08-19  9:49       ` Krzysztof Halasa
2003-08-19 10:15         ` Jes Sorensen
2003-08-19  9:03   ` Jes Sorensen
2003-08-19 13:07     ` Alan Cox
2003-08-19 13:20       ` Jes Sorensen
2003-08-19 16:55       ` David S. Miller
2003-08-19 18:33         ` Alan Cox
2003-08-19 18:31           ` David S. Miller
2003-08-19 20:31         ` Krzysztof Halasa [this message]
2003-08-22 11:54           ` Krzysztof Halasa
2003-08-23 17:11             ` Jes Sorensen
2003-08-24 12:06               ` Krzysztof Halasa
2003-08-24 13:00                 ` David S. Miller
2003-08-24 19:58                   ` Krzysztof Halasa
2003-08-25  8:50                     ` Jes Sorensen
2003-08-30 21:18                     ` Krzysztof Halasa
2003-08-31  1:50                       ` David S. Miller
2003-08-31 12:52                         ` Alan Cox
2003-08-31 15:24                           ` Krzysztof Halasa
2003-09-01  5:22                           ` David S. Miller
2003-09-01  7:34                             ` Krzysztof Halasa
2003-09-01  7:43                               ` David S. Miller
2003-09-01 17:14                                 ` Krzysztof Halasa
2003-09-01 17:28                                   ` David S. Miller
2003-09-01 18:24                                     ` Krzysztof Halasa
2003-09-01  7:54                             ` Alan Cox
2003-09-01  7:52                               ` David S. Miller
2003-09-01 16:27                                 ` Krzysztof Halasa
2003-09-01 17:33                                   ` David S. Miller
2003-08-25  8:47                 ` Jes Sorensen

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=m34r0dwfrr.fsf@defiant.pm.waw.pl \
    --to=khc@pm.waw.pl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=jes@wildopensource.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zaitcev@redhat.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 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).