linux-stable.git/drivers/scsi, branch v4.9.35

scsi: qla2xxx: Fix mailbox pointer error in fwdump capture

2017-06-14T13:06:02+00:00

commit 74939a0bc772d642b1c12827966c4c3a3c90ea2c upstream.

Signed-off-by: Joe Carnuccio 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Set bit 15 for DIAG_ECHO_TEST MBC

2017-06-14T13:06:02+00:00

commit 1d63496516c61e2e1351f10e6becbfc9ee511395 upstream.

Set bit (BIT_15) to send right ECHO payload information for Diagnostic
Echo Test command.

Signed-off-by: Joe Carnuccio 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: Modify T262 FW dump template to specify same start/end to debug customer issues

2017-06-14T13:06:02+00:00

commit ce6c668b146cc4f4442111e2bcee4c3af94e1ddf upstream.

Firmware dump allows for debugging customer issues. This patch fixes
start/end pointer calculation to capture T262 template entry for dump
tool.

Signed-off-by: Joe Carnuccio 
Signed-off-by: Himanshu Madhani 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: qla2xxx: don't disable a not previously enabled PCI device

2017-06-14T13:06:02+00:00

commit ddff7ed45edce4a4c92949d3c61cd25d229c4a14 upstream.

When pci_enable_device() or pci_enable_device_mem() fail in
qla2x00_probe_one() we bail out but do a call to
pci_disable_device(). This causes the dev_WARN_ON() in
pci_disable_device() to trigger, as the device wasn't enabled
previously.

So instead of taking the 'probe_out' error path we can directly return
*iff* one of the pci_enable_device() calls fails.

Additionally rename the 'probe_out' goto label's name to the more
descriptive 'disable_device'.

Signed-off-by: Johannes Thumshirn 
Fixes: e315cd28b9ef ("[SCSI] qla2xxx: Code changes for qla data structure refactoring")
Reviewed-by: Bart Van Assche 
Reviewed-by: Giridhar Malavali 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: mpt3sas: Force request partial completion alignment

2017-06-07T10:07:48+00:00

commit f2e767bb5d6ee0d988cb7d4e54b0b21175802b6b upstream.

The firmware or device, possibly under a heavy I/O load, can return on a
partial unaligned boundary. Scsi-ml expects these requests to be
completed on an alignment boundary. Scsi-ml blindly requeues the I/O
without checking the alignment boundary of the I/O request for the
remaining bytes. This leads to errors, since devices cannot perform
non-aligned read/write operations.

This patch fixes the issue in the driver. It aligns unaligned
completions of FS requests, by truncating them to the nearest alignment
boundary.

[mkp: simplified if statement]

Reported-by: Mauricio Faria De Oliveira 
Signed-off-by: Guilherme G. Piccoli 
Signed-off-by: Ram Pai 
Acked-by: Sreekanth Reddy 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ibmvscsis: Fix the incorrect req_lim_delta

2017-06-07T10:07:47+00:00

commit 75dbf2d36f6b122ad3c1070fe4bf95f71bbff321 upstream.

The current code is not correctly calculating the req_lim_delta.

We want to make sure vscsi->credit is always incremented when
we do not send a response for the scsi op. Thus for the case where
there is a successfully aborted task we need to make sure the
vscsi->credit is incremented.

v2 - Moves the original location of the vscsi->credit increment
to a better spot. Since if we increment credit, the next command
we send back will have increased req_lim_delta. But we probably
shouldn't be doing that until the aborted cmd is actually released.
Otherwise the client will think that it can send a new command, and
we could find ourselves short of command elements. Not likely, but could
happen.

This patch depends on both:
commit 25e78531268e ("ibmvscsis: Do not send aborted task response")
commit 98883f1b5415 ("ibmvscsis: Clear left-over abort_cmd pointers")

Signed-off-by: Bryant G. Ly 
Reviewed-by: Michael Cyr 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

ibmvscsis: Clear left-over abort_cmd pointers

2017-06-07T10:07:47+00:00

commit 98883f1b5415ea9dce60d5178877d15f4faa10b8 upstream.

With the addition of ibmvscsis->abort_cmd pointer within
commit 25e78531268e ("ibmvscsis: Do not send aborted task response"),
make sure to explicitly NULL these pointers when clearing
DELAY_SEND flag.

Do this for two cases, when getting the new new ibmvscsis
descriptor in ibmvscsis_get_free_cmd() and before posting
the response completion in ibmvscsis_send_messages().

Signed-off-by: Bryant G. Ly 
Reviewed-by: Michael Cyr 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

ibmvscsis: Do not send aborted task response

2017-05-25T13:44:37+00:00

commit 25e78531268e9240fc594ce76587601b873d37c9 upstream.

The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.

ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.

SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.

Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.

Signed-off-by: Bryant G. Ly 
Signed-off-by: Michael Cyr 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman

scsi: smartpqi: fix time handling

2017-05-14T12:00:20+00:00

commit ed10858eadd4988260c6bc7d75fc25176342b5a7 upstream.

When we have turned off RTC support, the smartpqi driver fails to build:

ERROR: "rtc_time64_to_tm" [drivers/scsi/smartpqi/smartpqi.ko] undefined!

This is easily avoided by using the generic 'struct tm' based helper rather
than the RTC specific one. While fixing this, I noticed that even though
the driver uses time64_t for storing seconds, it gets them from the
old 32-bit struct timeval. To address this, we can simplify the code
by calling ktime_get_real_seconds() directly.

Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver")
Signed-off-by: Arnd Bergmann 
Acked-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: mac_scsi: Fix MAC_SCSI=m option when SCSI=m

2017-05-14T12:00:19+00:00

commit 2559a1ef688f933835912c731bed2254146a9b04 upstream.

The mac_scsi driver still gets disabled when SCSI=m. This should have
been fixed back when I enabled the tristate but I didn't see the bug.

Fixes: 6e9ae6d560e1 ("[PATCH] mac_scsi: Add module option to Kconfig")
Signed-off-by: Finn Thain 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman