From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"James.Bottomley@HansenPartnership.com"
<James.Bottomley@HansenPartnership.com>,
"sathya.prakash@broadcom.com" <sathya.prakash@broadcom.com>,
"chaitra.basappa@broadcom.com" <chaitra.basappa@broadcom.com>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"suganath-prabu.subramani@broadcom.com"
<suganath-prabu.subramani@broadcom.com>
Cc: "hch@lst.de" <hch@lst.de>, "hare@suse.de" <hare@suse.de>,
"MPT-FusionLinux.pdl@broadcom.com"
<MPT-FusionLinux.pdl@broadcom.com>
Subject: Re: [PATCH 1/1] mpt3sas: Ignore unaligned completion length for ZBC_IN
Date: Tue, 14 Feb 2017 05:11:30 +0000 [thread overview]
Message-ID: <1487049066.6475.3.camel@sandisk.com> (raw)
In-Reply-To: <bb2092fe-4368-2a7f-3e67-6e8369fb4d56@wdc.com>
On Tue, 2017-02-14 at 13:42 +0900, Damien Le Moal wrote:
> I think so. But my understanding of REQ_TYPE_BLOCK_PC is that it is the
> type for requests issued internally (scsi_execute) of from things like
> the SG driver, so in essence, all requests not derived from a BIO... Is
> this correct ? If yes, then setting the BLOCK_TYPE_PC for
> REQ_OP_ZONE_REPORT (and REQ_OP_ZONE_RESET while at it) would break this
> model, wouldn't it ?
Hello Damien,
I think we want to keep the knowledge of which requests have a request size
that should be a multiple of the logical block size in the block layer core
or in the SCSI core but not in the mpt3sas driver. But I'm not sure what the
best approach is to do that. Should we use the request type, should we add a
new request attribute or should we add a new function?
Bart.
next prev parent reply other threads:[~2017-02-14 5:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 5:11 [PATCH 1/1] mpt3sas: Ignore unaligned completion length for ZBC_IN Damien Le Moal
2017-02-13 18:57 ` Bart Van Assche
2017-02-14 3:45 ` Damien Le Moal
2017-02-14 3:59 ` Bart Van Assche
2017-02-14 4:42 ` Damien Le Moal
2017-02-14 5:11 ` Bart Van Assche [this message]
2017-02-14 5:21 ` Damien Le Moal
2017-02-14 6:18 ` hch
2017-02-14 6:34 ` Damien Le Moal
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=1487049066.6475.3.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=Damien.LeMoal@wdc.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=chaitra.basappa@broadcom.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sathya.prakash@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.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