From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Boaz Harrosh <boaz@plexistor.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Bart Van Assche <bart.vanassche@sandisk.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 0/17] Clear up bidi command confusion
Date: Thu, 29 Jan 2015 06:41:29 -0800 [thread overview]
Message-ID: <1422542489.2091.2.camel@HansenPartnership.com> (raw)
In-Reply-To: <54CA2EDF.7060405@plexistor.com>
On Thu, 2015-01-29 at 15:00 +0200, Boaz Harrosh wrote:
> On 01/23/2015 03:12 PM, Christoph Hellwig wrote:
> > On Fri, Jan 23, 2015 at 01:05:30PM +0100, Bart Van Assche wrote:
> >> There is some confusion in the SCSI core and in SCSI LLDs around the
> >> meaning of sc_data_direction and whether or not this member can have the
> >> value DMA_BIDIRECTIONAL. Clear up this confusion. The patches in this
> >> series are:
> >
> > I wonder if we should change the code to set DMA_BIDIRECTIONAL for
> > bidi commands. That seems a lot more logical than the current
> > version.
> >
>
> You cannot do this. Because a Bidi Command is actually two commands
> one for the WRITE side (DMA_TO_DEVICE) which is this one, and another
> command for the READ side (DMA_FROM_DEVICE).
You're not thinking about this the correct way. DMA_BIDIRECTIONAL is a
DMA engine flag. We use it in SCSI for historical reasons (mainly to
prevent a translation from the SCSI version). Since it was never used,
most SCSI drivers have code to check and reject commands with it set.
For actual bidirectional commands, you have to check scsi_bidi_command()
and programme the DMA engine separately for both phases, so the flag is
useless in this case.
The proposal is to make it the signal for bidirectional commands (in
which case most HBAs would make it do the right thing; i.e. reject) but
it still wouldn't be how you'd program the DMA enigne; that still would
have to be done in two phases as it is today.
James
next prev parent reply other threads:[~2015-01-29 14:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 12:05 [PATCH 0/17] Clear up bidi command confusion Bart Van Assche
2015-01-23 12:06 ` [PATCH 01/17] Clear up sc_data_direction documentation Bart Van Assche
2015-01-23 12:06 ` [PATCH 02/17] Clean up scsi_ioctl_reset() Bart Van Assche
2015-01-23 12:07 ` [PATCH 03/17] sg: Remove an unused variable Bart Van Assche
2015-01-23 12:30 ` Douglas Gilbert
2015-01-23 12:07 ` [PATCH 04/17] dpt_i2o: Fix bidi command test Bart Van Assche
2015-01-23 12:08 ` [PATCH 05/17] aachba: " Bart Van Assche
2015-01-23 12:08 ` [PATCH 06/17] eata: Remove dead code Bart Van Assche
2015-01-23 12:09 ` [PATCH 07/17] sbp2: Fix bidi command test Bart Van Assche
2015-01-23 14:05 ` Stefan Richter
2015-01-23 12:10 ` [PATCH 08/17] ibmvscsi: " Bart Van Assche
2015-01-27 22:10 ` Tyrel Datwyler
2015-01-28 7:57 ` Bart Van Assche
2015-01-28 22:42 ` Tyrel Datwyler
2015-01-23 12:10 ` [PATCH 09/17] cciss: Remove dead code Bart Van Assche
2015-01-23 12:11 ` [PATCH 10/17] hpsa: " Bart Van Assche
2015-01-23 12:11 ` [PATCH 11/17] 3w-9xxx: " Bart Van Assche
2015-01-23 12:12 ` [PATCH 12/17] ncr53c8xx: Fix bidi command support Bart Van Assche
2015-01-23 12:13 ` [PATCH 13/17] qla1280: " Bart Van Assche
2015-01-23 12:13 ` [PATCH 14/17] 53c700: Remove dead code Bart Van Assche
2015-01-23 12:14 ` [PATCH 15/17] mvumi: " Bart Van Assche
2015-01-23 12:15 ` [PATCH 16/17] sym_glue: Fix bidi command test Bart Van Assche
2015-01-23 12:17 ` [PATCH 17/17] IB/srp: Detect bidi commands properly Bart Van Assche
2015-01-25 16:58 ` Sagi Grimberg
2015-01-23 13:12 ` [PATCH 0/17] Clear up bidi command confusion Christoph Hellwig
2015-01-26 9:58 ` Bart Van Assche
2015-01-29 13:07 ` Boaz Harrosh
2015-01-29 13:20 ` Bart Van Assche
2015-01-29 14:43 ` Boaz Harrosh
2015-01-29 13:00 ` Boaz Harrosh
2015-01-29 14:41 ` James Bottomley [this message]
2015-01-29 14:56 ` Boaz Harrosh
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=1422542489.2091.2.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=bart.vanassche@sandisk.com \
--cc=boaz@plexistor.com \
--cc=hch@infradead.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 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.