talos-op-linux/drivers, branch v4.8.5

Revert "target: Fix residual overflow handling in target_complete_cmd_with_length"

2016-10-28T07:45:31+00:00

commit 61f36166c245e563c7a2b624f4c78c5ce0f680d6 upstream. This reverts commit c1ccbfe0311e2380a6d2dcb0714b36904f5d586f. Reverting this patch, as it incorrectly assumes the additional length for INQUIRY in target_complete_cmd_with_length() is SCSI allocation length, which breaks existing user-space code when SCSI allocation length is smaller than additional length. root@scsi-mq:~# sg_inq --len=4 -vvvv /dev/sdb found bsg_major=253 open /dev/sdb with flags=0x800 inquiry cdb: 12 00 00 00 04 00 duration=0 ms inquiry: pass-through requested 4 bytes (data-in) but got -28 bytes inquiry: pass-through can't get negative bytes, say it got none inquiry: got too few bytes (0) INQUIRY resid (32) should never exceed requested len=4 inquiry: failed requesting 4 byte response: Malformed response to SCSI command [resid=32] AFAICT the original change was not to address a specific host issue, so go ahead and revert to original logic for now. Cc: Douglas Gilbert Cc: Martin K. Petersen Cc: Sumit Rai Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code

2016-10-28T07:45:31+00:00

commit 926317de33998c112c5510301868ea9aa34097e2 upstream. This patch addresses a bug where a local EXTENDED_COPY WRITE or READ backend I/O request would always return SAM_STAT_CHECK_CONDITION, even if underlying xcopy_pt_cmd->se_cmd generated a different SCSI status code. ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios, and SAM_STAT_CHECK_CONDITION results in non-retriable status for these cases. Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy. Reported-by: Nixon Vincent Tested-by: Nixon Vincent Cc: Nixon Vincent Tested-by: Dinesh Israni Signed-off-by: Dinesh Israni Cc: Dinesh Israni Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE

2016-10-28T07:45:31+00:00

commit 449a137846c84829a328757cd21fd9ca65c08519 upstream. This patch addresses a bug where EXTENDED_COPY across multiple LUNs results in a CHECK_CONDITION when the source + destination are not located on the same physical node. ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE NOT REACHABLE to be returned when this occurs, in order to signal fallback to local copy method. As described in section 6.3.3 of spc4r22: "If it is not possible to complete processing of a segment because the copy manager is unable to establish communications with a copy target device, because the copy target device does not respond to INQUIRY, or because the data returned in response to INQUIRY indicates an unsupported logical unit, then the EXTENDED COPY command shall be terminated with CHECK CONDITION status, with the sense key set to COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE NOT REACHABLE." Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes. Reported-by: Nixon Vincent Tested-by: Nixon Vincent Cc: Nixon Vincent Tested-by: Dinesh Israni Signed-off-by: Dinesh Israni Cc: Dinesh Israni Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target: Re-add missing SCF_ACK_KREF assignment in v4.1.y

2016-10-28T07:45:31+00:00

commit 527268df31e57cf2b6d417198717c6d6afdb1e3e upstream. This patch fixes a regression in >= v4.1.y code where the original SCF_ACK_KREF assignment in target_get_sess_cmd() was dropped upstream in commit 054922bb, but the series for addressing TMR ABORT_TASK + LUN_RESET with fabric session reinstatement in commit febe562c20 still depends on this code in transport_cmd_finish_abort(). The regression manifests itself as a se_cmd->cmd_kref +1 leak, where ABORT_TASK + LUN_RESET can hang indefinately for a specific I_T session for drivers using SCF_ACK_KREF, resulting in hung kthreads. This patch has been verified with v4.1.y code. Reported-by: Vaibhav Tandon Tested-by: Vaibhav Tandon Cc: Vaibhav Tandon Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

target/tcm_fc: use CPU affinity for responses

2016-10-28T07:45:31+00:00

commit 1ba0158fa66b5b2c597a748f87be1650c9960ccc upstream. The libfc stack assigns exchange IDs based on the CPU the request was received on, so we need to send the responses via the same CPU. Otherwise the send logic gets confuses and responses will be delayed, causing exchange timeouts on the initiator side. Signed-off-by: Hannes Reinecke Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led

2016-10-28T07:45:30+00:00

commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 upstream. Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device, must be done when it's runtime resumed. Currently this isn't case when changing the led, so let's fix this by adding a pm_runtime_get_sync() and a pm_runtime_put() around those operations. Reported-by: Ritesh Raj Sarraf Tested-by: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused

2016-10-28T07:45:30+00:00

commit 31cf742f515c275d22843c4c756e048d2b6d716c upstream. The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no SD card is inserted. This is wrong, as it could cause the device to remain runtime resumed when it's unused. Fix this behaviour. Tested-by: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: switch to 1V8 or 1V2 for hs400es mode

2016-10-28T07:45:30+00:00

commit 1720d3545b772c49b2975eeb3b8f4d3f56dc2085 upstream. When introducing hs400es, I didn't notice that we haven't switched voltage to 1V2 or 1V8 for it. That happens to work as the first controller claiming to support hs400es, arasan(5.1), which is designed to only support 1V8. So the voltage is fixed to 1V8. But it actually is wrong, and will not fit for other host controllers. Let's fix it. Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support") Signed-off-by: Shawn Lin Reviewed-by: Douglas Anderson Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

mmc: core: Annotate cmd_hdr as __le32

2016-10-28T07:45:30+00:00

commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 upstream. Commit f68381a70bb2 (mmc: block: fix packed command header endianness) correctly fixed endianness handling of packed_cmd_hdr in mmc_blk_packed_hdr_wrq_prep. But now, sparse complains about incorrect types: drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types) drivers/mmc/card/block.c:1613:27: expected unsigned int [unsigned] [usertype] drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] ... So annotate cmd_hdr properly using __le32 to make everyone happy. Signed-off-by: Jiri Slaby Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness) Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman

memstick: rtsx_usb_ms: Manage runtime PM when accessing the device

2016-10-28T07:45:29+00:00

commit 9158cb29e7c2f10dd325eb1589f0fe745a271257 upstream. Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. This is currently not the case and it could trigger various errors. Fix this by properly deal with runtime PM in this regards. This means making sure the device is runtime resumed, when serving requests via the ->request() callback or changing settings via the ->set_param() callbacks. Cc: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman