public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	berkley@cs.wustl.edu
Subject: Re: [BUG] x86_64 pci_map_sg modifies sg list - fails multiple map/unmaps
Date: Mon, 5 Jan 2004 11:22:02 -0800	[thread overview]
Message-ID: <20040105112202.1fe5cacf.davem@redhat.com> (raw)
In-Reply-To: <2938942704.1073325455@aslan.btc.adaptec.com>

On Mon, 05 Jan 2004 10:57:35 -0700
"Justin T. Gibbs" <gibbs@scsiguy.com> wrote:

> DMA-API.txt doesn't seem to cover this issue.  Should the low-level DMA
> code restore the S/G list to its original state on unmap or should the
> SCSI HBA drivers be changed to update "use_sg" with the segment count
> reported by the pci_map_sg() API?  If the latter, this seems to contradict
> the mandate in DMA-API that the nseg parameter passed into the unmap call
> be the same as that passed into the map call.  Most of the kernel assumes
> that an S/G list can be mapped an unmapped multiple times using the same
> arguments.  This doesn't seem to me to be an unreasonable expectation.

No, the PCI layer is not required at all to restore the SG to it's original state
if it does DMA page coalescing as sparc64 and x86_64 do.

But I don't see what the real problem is, all the PCI layer is doing is setting up
the DMA address/length pairs in the entries that are needed, then returning
the number of such slots that exist.  You, in your driver, can remember the original
total number of physical entries and use that value to pass things back in.

  reply	other threads:[~2004-01-05 19:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-05 17:57 [BUG] x86_64 pci_map_sg modifies sg list - fails multiple map/unmaps Justin T. Gibbs
2004-01-05 19:22 ` David S. Miller [this message]
2004-01-05 19:41 ` Badari Pulavarty
2004-01-05 19:47 ` Andi Kleen
2004-01-05 20:04   ` Justin T. Gibbs
2004-01-05 20:35   ` David S. Miller
2004-01-05 21:10     ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-01-05 19:29 Berkley Shands
2004-01-05 19:28 ` David S. Miller
2004-01-05 20:00 Berkley Shands
     [not found] <2938942704.1073325455@aslan.btc.adaptec.com.suse.lists.linux.kernel>
     [not found] ` <m3brpi41q0.fsf@averell.firstfloor.org.suse.lists.linux.kernel>
     [not found]   ` <2997092704.1073333041@aslan.btc.adaptec.com.suse.lists.linux.kernel>
2004-01-05 20:58     ` Andi Kleen
     [not found] <200401051929.i05JTsM0000014248@mudpuddle.cs.wustl.edu.suse.lists.linux.kernel>
     [not found] ` <20040105112800.7a9f240b.davem@redhat.com.suse.lists.linux.kernel>
2004-01-05 21:02   ` Andi Kleen
2004-01-05 21:01     ` David S. Miller
2004-01-05 21:31       ` Andi Kleen
2004-01-06  0:05         ` James Bottomley
2004-01-06  3:06           ` Andi Kleen
2004-01-06  3:04             ` David S. Miller
2004-01-06  3:14               ` James Bottomley
2004-01-07 15:35 Berkley Shands
2004-01-07 19:19 ` badari
2004-01-07 16:33 Berkley Shands

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=20040105112202.1fe5cacf.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=berkley@cs.wustl.edu \
    --cc=gibbs@scsiguy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox