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: jes@trained-monkey.org, alan@lxorguk.ukuu.org.uk,
	zaitcev@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: kills consistent_dma_mask
Date: 30 Aug 2003 23:18:50 +0200	[thread overview]
Message-ID: <m365kex2rp.fsf@defiant.pm.waw.pl> (raw)
In-Reply-To: <m365kmltdy.fsf@defiant.pm.waw.pl>

David, any comments?

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

> > The code has to get the mask anyway, either from
> > pci_dev->(consistent_)dma_mask or from its arguments.
> 
> But it does not have to verify the mask each and every mapping call
> currently.  We'll need to do that with your suggested changes.

No, why? What we'll need is to verify the mask at driver startup.
It would be driver responsibility to use only valid (verified) masks.

> Nobody is going to agree to any of your proposals at the rate you're
> currently going.

What do you propose instead?

> Effectively, the correct effects are obtained on i386, Alpha,
> IA64, and sparc for all drivers in the tree.  I can say this because
> nobody tries to do anything interesting with consistent_dma_mask
> yet, and that is why nobody has any incentive to "fix" it as you
> keep complaining we need to do.

False. I have a device which needs different mask for consistent allocs.
In fact the whole story began with me trying to put this driver into
the tree.

> See, to show something is broken, you have to show a device that
> will break currently.

SBE wanXL sync serial adapter. 32 bits for buffers but 28 bits for
consistent data.

>  The consistent_dma_mask is only modified
> by tg3, and it does so in such a way that all platforms work properly.

I can't imagine all devices work properly on all platforms wrt
consistent allocs. Say, sound drivers setting only dma_mask to < 32 bits
and expecting consistent alloc will use that and not consistent_dma_mask.

Of course, there is a question if we want to support such sound cards
on Itaniums and Opterons? Of course they work on i386 as
i386 pci_alloc_consistent() ignores consistent_dma_mask.

-- Krzysztof Halasa, B*FH

  parent reply	other threads:[~2003-08-30 21:19 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
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 [this message]
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=m365kex2rp.fsf@defiant.pm.waw.pl \
    --to=khc@pm.waw.pl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@redhat.com \
    --cc=jes@trained-monkey.org \
    --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).