public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "hch@lst.de" <hch@lst.de>
To: Damien Le Moal <damien.lemoal@wdc.com>
Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>,
	"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>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"suganath-prabu.subramani@broadcom.com"
	<suganath-prabu.subramani@broadcom.com>,
	"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 07:18:26 +0100	[thread overview]
Message-ID: <20170214061826.GA10552@lst.de> (raw)
In-Reply-To: <6cabab36-3865-1465-fae8-69c437602b80@wdc.com>

On Tue, Feb 14, 2017 at 02:21:37PM +0900, Damien Le Moal wrote:
> > 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?
> 
> I agree. But the mpt3sas patch that introduced the problem is to solve
> problems with a buggy hardware in the first place... A quirck of some
> sort. So do we really need such a big change just the report zones
> exception ? (all other REQ_TYPE_FS commands either have no payload or
> the payload size is LBA aligned)
> 
> Martin, James, Hannes,
> 
> Please advise ! 4.10 is introducing zoned block device support, and from
> the first release that will be broken with mpt3sas HBAs if we do not
> patch this. Any preferred approach ?

I suspect we'll need to move the workaround to the SD driver.  While it's
an mpt bug, sd is the party that knows which kind of requests were
generated, so it's where we can fix up the length in the done callback.

  reply	other threads:[~2017-02-14  6:18 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
2017-02-14  5:21           ` Damien Le Moal
2017-02-14  6:18             ` hch [this message]
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=20170214061826.GA10552@lst.de \
    --to=hch@lst.de \
    --cc=Bart.VanAssche@sandisk.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=MPT-FusionLinux.pdl@broadcom.com \
    --cc=chaitra.basappa@broadcom.com \
    --cc=damien.lemoal@wdc.com \
    --cc=hare@suse.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