linux-toradex.git/drivers/scsi, branch v3.2.61

megaraid: Use resource_size_t for PCI resources, not long

2014-07-11T12:33:58+00:00

commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream.

The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to
truncation of the PCI resource address, meaning this driver didn't work
on 32-bit systems with 64-bit PCI adressing ranges.

Signed-off-by: Ben Collins 
Acked-by: Sumit Saxena 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Fix spurious request sense in error handling

2014-07-11T12:33:58+00:00

commit d555a2abf3481f81303d835046a5ec2c4fb3ca8e upstream.

We unconditionally execute scsi_eh_get_sense() to make sure all failed
commands that should have sense attached, do.  However, the routine forgets
that some commands, because of the way they fail, will not have any sense code
... we should not bother them with a REQUEST_SENSE command.  Fix this by
testing to see if we actually got a CHECK_CONDITION return and skip asking for
sense if we don't.

Tested-by: Alan Stern 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

dual scan thread bug fix

2014-07-11T12:33:56+00:00

commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.

In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it.  In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.

Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.

Tested-by: Sarah Sharp 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

fix our current target reap infrastructure

2014-07-11T12:33:56+00:00

commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.

This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs.  The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible.  This
ensures that the target disappears as soon as the last device is gone
rather than waiting until final release of the device (which is often
too long).

Reviewed-by: Alan Stern 
Tested-by: Sarah Sharp 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

Stop accepting SCSI requests before removing a device

2014-07-11T12:33:55+00:00

commit b485462aca7df4e32bcf7efb6f84a69e8b640243 upstream.

Avoid that the code for requeueing SCSI requests triggers a
crash by making sure that that code isn't scheduled anymore
after a device has been removed.

Also, source code inspection of __scsi_remove_device() revealed
a race condition in this function: no new SCSI requests must be
accepted for a SCSI device after device removal started.

Signed-off-by: Bart Van Assche 
Reviewed-by: Mike Christie 
Acked-by: Tejun Heo 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

mpt2sas: Don't disable device twice at suspend.

2014-06-09T12:29:04+00:00

commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream.

On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which
in turn calls pci_disable_device if the device is enabled prior to
suspending. However, _scsih_suspend also calls pci_disable_device
itself.

Thus, in the event that the device is enabled prior to suspending,
pci_disable_device will be called twice. This patch removes the
duplicate call to pci_disable_device in _scsi_suspend as it is both
unnecessary and results in a kernel oops.

Signed-off-by: Tyler Stachecki 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

Revert "isci: fix reset timeout handling"

2014-04-30T15:23:27+00:00

This reverts commit 584ec12265192bf49dfa270d517380f6723a6956, which
was commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream.  It
causes boot failure on 3.2 although no such problem occurs upstream.

Reported-by: Ondrej Zary 
Signed-off-by: Ben Hutchings 
Acked-by: Dan Williams

qla2xxx: Poll during initialization for ISP25xx and ISP83xx

2014-04-01T23:58:58+00:00

commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream.

Signed-off-by: Giridhar Malavali 
Signed-off-by: Saurav Kashyap 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2:
 - Adjust context
 - QLA83XX was not included]
Signed-off-by: Ben Hutchings

isci: correct erroneous for_each_isci_host macro

2014-04-01T23:58:58+00:00

commit c59053a23d586675c25d789a7494adfdc02fba57 upstream.

In the first place, the loop 'for' in the macro 'for_each_isci_host'
(drivers/scsi/isci/host.h:314) is incorrect, because it accesses
the 3rd element of 2 element array. After the 2nd iteration it executes
the instruction:
        ihost = to_pci_info(pdev)->hosts[2]
(while the size of the 'hosts' array equals 2) and reads an
out of range element.

In the second place, this loop is incorrectly optimized by GCC v4.8
(see http://marc.info/?l=linux-kernel&m=138998871911336&w=2).
As a result, on platforms with two SCU controllers,
the loop is executed more times than it can be (for i=0,1 and 2).
It causes kernel panic during entering the S3 state
and the following oops after 'rmmod isci':

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __list_add+0x1b/0xc0
Oops: 0000 [#1] SMP
RIP: 0010:[]  [] __list_add+0x1b/0xc0
Call Trace:
  [] __mutex_lock_slowpath+0x114/0x1b0
  [] mutex_lock+0x1f/0x30
  [] sas_disable_events+0x1b/0x50 [libsas]
  [] sas_unregister_ha+0x18/0x60 [libsas]
  [] isci_unregister+0x1e/0x40 [isci]
  [] isci_pci_remove+0x5d/0x100 [isci]
  [] pci_device_remove+0x3b/0xb0
  [] __device_release_driver+0x7f/0xf0
  [] driver_detach+0xa8/0xb0
  [] bus_remove_driver+0x9b/0x120
  [] driver_unregister+0x2c/0x50
  [] pci_unregister_driver+0x23/0x80
  [] isci_exit+0x10/0x1e [isci]
  [] SyS_delete_module+0x16b/0x2d0
  [] ? do_notify_resume+0x61/0xa0
  [] system_call_fastpath+0x16/0x1b

The loop has been corrected.
This patch fixes kernel panic during entering the S3 state
and the above oops.

Signed-off-by: Lukasz Dorau 
Reviewed-by: Maciej Patelczyk 
Tested-by: Lukasz Dorau 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
Signed-off-by: Ben Hutchings

isci: fix reset timeout handling

2014-04-01T23:58:58+00:00

commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream.

Remove an erroneous BUG_ON() in the case of a hard reset timeout.  The
reset timeout handler puts the port into the "awaiting link-up" state.
The timeout causes the device to be disconnected and we need to be in
the awaiting link-up state to re-connect the port.  The BUG_ON() made
the incorrect assumption that resets never timeout and we always
complete the reset in the "resetting" state.

Testing this patch also uncovered that libata continues to attempt to
reset the port long after the driver has torn down the context.  Once
the driver has committed to abandoning the link it must indicate to
libata that recovery ends by returning -ENODEV from
->lldd_I_T_nexus_reset().

Acked-by: Lukasz Dorau 
Reported-by: David Milburn 
Reported-by: Xun Ni 
Tested-by: Xun Ni 
Signed-off-by: Dan Williams 
Signed-off-by: James Bottomley 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings