From: Jens Axboe <axboe@suse.de>
To: "David S. Miller" <davem@redhat.com>
Cc: groudier@free.fr, linux-kernel@vger.kernel.org
Subject: Re: [patch] block-highmem-all-18
Date: Fri, 16 Nov 2001 23:45:55 +0100 [thread overview]
Message-ID: <20011116234555.C11826@suse.de> (raw)
In-Reply-To: <20011116093927.E27010@suse.de> <20011116193057.O1825-100000@gerard> <20011116.135409.118971851.davem@redhat.com>
In-Reply-To: <20011116.135409.118971851.davem@redhat.com>
On Fri, Nov 16 2001, David S. Miller wrote:
> From: Gérard Roudier <groudier@free.fr>
> Date: Fri, 16 Nov 2001 19:59:02 +0100 (CET)
>
> On Fri, 16 Nov 2001, Jens Axboe wrote:
>
> > - Add sym2 can_dma_32 flag (me)
> ^^^^^^^^^^ Pooaaahhh!:) What's this utter oddity ?
> Only dma 32 ? :-)
>
> It is workaround for buggy drivers, when set it means that single SG
> list entry request will be handled correctly. When clear it means
> that single entry SG lists are to be avoided by the block layer.
>
> Many devices would explode when given single entry scatterlist. :(
>
> It's naming is questionable... that I agree with. The name should be
> more suggestive to what it really means.
Heh, actually Dave the single_sg_ok flag used to specify just that, but
Arjan noted that we never needed to trust that functionality when
!can_dma_32. So now can_dma_32 being set implies that the HBA driver
also gets the single sg entry correct.
To answer Gerard's question -- with can_dma_32 set, scsi_merge will set
the correct bounce value based on the PCI device DMA mask set. So dma_32
is indeed a misnomer, it was introduced before we supported full 64-bit
dma, and should now just be called can_highmem_io or something similar.
--
Jens Axboe
next prev parent reply other threads:[~2001-11-16 22:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 8:39 [patch] block-highmem-all-18 Jens Axboe
2001-11-16 18:59 ` Gérard Roudier
2001-11-16 21:54 ` David S. Miller
2001-11-16 20:12 ` Gérard Roudier
2001-11-16 22:45 ` Jens Axboe [this message]
2001-11-16 23:05 ` David S. Miller
2001-11-16 23:16 ` Jens Axboe
2001-11-16 22:52 ` Jens Axboe
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=20011116234555.C11826@suse.de \
--to=axboe@suse.de \
--cc=davem@redhat.com \
--cc=groudier@free.fr \
--cc=linux-kernel@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 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.