- 11 Sep, 2019 10 commits
-
-
Xiang Chen authored
Currently the NCQ tag is only assigned for FPDMA READ and FPDMA WRITE commands, and for other NCQ commands (such as FPDMA SEND), their NCQ tags are set in the delivery command to 0. So for all the NCQ commands, we also need to assign normal NCQ tag for them, so drop the command type check in hisi_sas_get_ncq_tag() [drop hisi_sas_get_ncq_tag() altogether actually], and always use the ATA command NCQ tag when appropriate. Link: https://lore.kernel.org/r/1567774537-20003-8-git-send-email-john.garry@huawei.comSigned-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Xiang Chen authored
After suspend and resume, the HW registers will be set back to their initial value. We use init_reg_v3_hw() to set some registers, but some registers are set via firmware in ACPI "_RST" method, so add reset handler before init_reg_v3_hw(). Link: https://lore.kernel.org/r/1567774537-20003-7-git-send-email-john.garry@huawei.comSigned-off-by:
-
Xiang Chen authored
When init device for SAS disks, it will send TMF IO to clear disks. At that time TMF IO is broken by some operations such as injecting controller reset from HW RAs event, the TMF IO will be timeout, and at last device will be gone. Print is as followed: hisi_sas_v3_hw 0000:74:02.0: dev[240:1] found ... hisi_sas_v3_hw 0000:74:02.0: controller resetting... hisi_sas_v3_hw 0000:74:02.0: phyup: phy7 link_rate=10(sata) hisi_sas_v3_hw 0000:74:02.0: phyup: phy0 link_rate=9(sata) hisi_sas_v3_hw 0000:74:02.0: phyup: phy1 link_rate=9(sata) hisi_sas_v3_hw 0000:74:02.0: phyup: phy2 link_rate=9(sata) hisi_sas_v3_hw 0000:74:02.0: phyup: phy3 link_rate=9(sata) hisi_sas_v3_hw 0000:74:02.0: phyup: phy6 link_rate=10(sata) hisi_sas_v3_hw 0000:74:02.0: phyup: phy5 link_rate=11 hisi_sas_v3_hw 0000:74:02.0: phyup: phy4 link_rate=11 hisi_sas_v3_hw 0000:74:02.0: controller reset complete hisi_sas_v3_hw 0000:74:02.0: abort tmf: TMF task timeout and not done hisi_sas_v3_hw 0000:74:02.0: dev[240:1] is gone sas: driver on host 0000:74:02.0 cannot handle device 5000c500a75a860d, error:5 To improve the reliability, retry TMF IO max of 3 times for SAS disks which is the same as softreset does. Link: https://lore.kernel.org/r/1567774537-20003-6-git-send-email-john.garry@huawei.comSigned-off-by:
-
Luo Jiaxing authored
At expander environment, we delay after issue phy reset to wait for hardware to handle phy reset. But if sas_smp_phy_control() fails, the delay is unnecessary so remove it. Link: https://lore.kernel.org/r/1567774537-20003-5-git-send-email-john.garry@huawei.comSigned-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
-
Luo Jiaxing authored
At hisi_sas_debug_I_T_nexus_reset(), we call sas_phy_reset() to reset a phy. But if the phy is disabled, sas_phy_reset() will directly return -ENODEV without issue a phy reset request. If so, We can directly return -ENODEV to libsas before issue a phy reset. Link: https://lore.kernel.org/r/1567774537-20003-4-git-send-email-john.garry@huawei.comSigned-off-by:
-
Luo Jiaxing authored
When calling sas_phy_reset(), we need to specify whether the reset type is hard reset or link reset - use true/false for clarity. Link: https://lore.kernel.org/r/1567774537-20003-3-git-send-email-john.garry@huawei.comSigned-off-by:
-
Luo Jiaxing authored
This trigger is add at _hisi_sas_internal_task_abort() Link: https://lore.kernel.org/r/1567774537-20003-2-git-send-email-john.garry@huawei.comSigned-off-by:
-
Matt Lupfer authored
The event handler calls scsi_scan_host() when events are missed, which will hotplug new LUNs. However, this function won't remove any unplugged LUNs. The result is that hotunplug doesn't work properly when the number of unplugged LUNs exceeds the event queue size (currently 8). Scan existing LUNs when events are missed to check if they are still present. If not, remove them. Link: https://lore.kernel.org/r/20190905181903.29756-1-mlupfer@ddn.comSigned-off-by:
Matt Lupfer <mlupfer@ddn.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Martin Wilck authored
cdb in send_mode_select() is not zeroed and is only partially filled in rdac_failover_get(), which leads to some random data getting to the device. Users have reported storage responding to such commands with INVALID FIELD IN CDB. Code before commit 32782557 was not affected, as it called blk_rq_set_block_pc(). Fix this by zeroing out the cdb first. Identified & fix proposed by HPE. Fixes: 32782557 ("scsi_dh_rdac: switch to scsi_execute_req_flags()") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20190904155205.1666-1-martin.wilck@suse.comSigned-off-by:
Martin Wilck <mwilck@suse.com> Acked-by:
Ales Novak <alnovak@suse.cz> Reviewed-by:
Shane Seymour <shane.seymour@hpe.com> Signed-off-by:
-
zhengbin authored
In fcoe_if_init, if fc_attach_transport(&fcoe_vport_fc_functions) fails, need to free the previously memory and return fail, otherwise will trigger null-ptr-deref Read in fc_release_transport. fcoe_exit fcoe_if_exit fc_release_transport(fcoe_vport_scsi_transport) Link: https://lore.kernel.org/r/1566279789-58207-1-git-send-email-zhengbin13@huawei.comReported-by:Hulk Robot <hulkci@huawei.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Signed-off-by:
-
- 07 Sep, 2019 17 commits
-
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Link: https://lore.kernel.org/r/20190904130457.24744-1-yuehaibing@huawei.comReported-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Acked-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Link: https://lore.kernel.org/r/20190904130348.24772-1-yuehaibing@huawei.comReported-by:
-
YueHaibing authored
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Link: https://lore.kernel.org/r/20190904130256.24704-1-yuehaibing@huawei.comReported-by:
-
YueHaibing authored
Use kmemdup rather than duplicating its implementation Link: https://lore.kernel.org/r/20190831124424.18642-1-yuehaibing@huawei.comSigned-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Bjorn Andersson authored
Specify the UFS device-reset gpio for db845c and mtp, so that the controller will issue a reset of the UFS device. Link: https://lore.kernel.org/r/20190828191756.24312-4-bjorn.andersson@linaro.orgSigned-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
Bjorn Andersson authored
The UFS_RESET pin on Qualcomm SoCs are controlled by TLMM and exposed through the GPIO framework. Acquire the device-reset GPIO and use this to implement the device_reset vops, to allow resetting the attached memory. Based on downstream support implemented by Subhash Jadavani <subhashj@codeaurora.org>. Link: https://lore.kernel.org/r/20190828191756.24312-3-bjorn.andersson@linaro.orgSigned-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Bjorn Andersson authored
Some UFS memory devices needs their reset line toggled in order to get them into a good state for initialization. Provide a new vops to allow the platform driver to implement this operation. Link: https://lore.kernel.org/r/20190828191756.24312-2-bjorn.andersson@linaro.orgSigned-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Bean Huo <beanhuo@micron.com> Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Acked-by:
-
James Smart authored
A recent patch unconditionally marks the hba as in error as part of resetting the adapter. The driver flow that called the adapter reset was a recovery path, which expects the adapter to not be in an error state in order to finish the recovery. Given the new error state being set, the recovery fails and the adapter is left in limbo. Revise the adapter reset routine so that it will only mark the adapter in error if it was unable to reset the adapter. Fixes: 8c24a4f6 ("scsi: lpfc: Fix crash due to port reset racing vs adapter error handling") Link: https://lore.kernel.org/r/20190903215441.10490-1-jsmart2021@gmail.comSigned-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
Sakari Ailus authored
Convert the remaining %pf users to %ps to prepare for the removal of the old %pf conversion specifier support. Fixes: 32350664 ("scsi: lpfc: Migrate to %px and %pf in kernel print calls") Link: https://lore.kernel.org/r/20190904160423.3865-1-sakari.ailus@linux.intel.comSigned-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Himanshu Madhani authored
Signed-off-by:
Himanshu Madhani <hmadhani@marvell.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Link: https://lore.kernel.org/r/20190830222402.23688-7-hmadhani@marvell.comSigned-off-by:
-
Quinn Tran authored
On fast cable pull, where driver is unable to detect device has disappeared and came back based on switch info, qla2xxx would not re-login while remote port has already invalidated the session. This causes IO timeout. This patch would relogin to remote device for RSCN affected port. Signed-off-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
-
Quinn Tran authored
Login session was stucked on cable pull. When FW is in the middle PRLI PENDING + driver is in Initiator mode, driver fails to check back with FW to see if the PRLI has completed. This patch would re-check with FW again to make sure PRLI would complete before pushing forward with relogin. Signed-off-by:
-
Himanshu Madhani authored
HINT_MBX_INT_PENDING is not guaranteed to be cleared by firmware. Remove check that prevent driver load with ISP82XX. Signed-off-by:
-
Quinn Tran authored
Use adapter specific callback to read flash instead of ISP adapter specific. Signed-off-by:
-
Himanshu Madhani authored
This patch updates log message which indicates number of vectors used by the driver instead of displaying failure to get maximum requested vectors. Driver will always request maximum vectors during initialization. In the event driver is not able to get maximum requested vectors, it will adjust the allocated vectors. This is normal and does not imply failure in driver. Signed-off-by:
Lee Duncan <lduncan@suse.com> Link: https://lore.kernel.org/r/20190830222402.23688-2-hmadhani@marvell.comSigned-off-by:
-
Damien Le Moal authored
For commands completing with a resid not aligned on the device logical sector size, also print the command CDB in addition to the current message to help debug hardware generating such incorrect command completion information. Link: https://lore.kernel.org/r/20190828053511.14818-1-damien.lemoal@wdc.comSigned-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Govindarajulu Varadarajan authored
pci_alloc_irq_vectors() returns number of vectors allocated. Fix the check for error condition. Fixes: cca678df ("scsi: fnic: switch to pci_alloc_irq_vectors") Link: https://lore.kernel.org/r/20190827211340.1095-1-gvaradar@cisco.comSigned-off-by:
Govindarajulu Varadarajan <gvaradar@cisco.com> Acked-by:
Satish Kharat <satishkh@cisco.com> Signed-off-by:
-
- 30 Aug, 2019 1 commit
-
-
John Pittman authored
Port speed printing was added by commit d948e638 ("scsi: fnic: Add port speed stat to fnic debug stats"). As currently configured, this will cause the port speed to be printed to syslog every 2 seconds. To prevent log spamming, only print the vnic port speed at driver initialization and if the speed changes. Also clean up a small typo in fnic_trace.c. Fixes: d948e638 ("scsi: fnic: Add port speed stat to fnic debug stats") Signed-off-by:
John Pittman <jpittman@redhat.com> Reviewed-by:
-
- 29 Aug, 2019 12 commits
-
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/bnx2fc/bnx2fc_hwi.c: In function bnx2fc_process_unsol_compl: drivers/scsi/bnx2fc/bnx2fc_hwi.c:636:30: warning: variable task set but not used [-Wunused-but-set-variable] drivers/scsi/bnx2fc/bnx2fc_hwi.c: In function bnx2fc_process_ofld_cmpl: drivers/scsi/bnx2fc/bnx2fc_hwi.c:1125:21: warning: variable port set but not used [-Wunused-but-set-variable] drivers/scsi/bnx2fc/bnx2fc_hwi.c: In function bnx2fc_init_seq_cleanup_task: drivers/scsi/bnx2fc/bnx2fc_hwi.c:1468:30: warning: variable orig_task set but not used [-Wunused-but-set-variable] Reported-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/bnx2fc/bnx2fc_io.c: In function bnx2fc_initiate_seq_cleanup: drivers/scsi/bnx2fc/bnx2fc_io.c:932:19: warning: variable lport set but not used [-Wunused-but-set-variable] drivers/scsi/bnx2fc/bnx2fc_io.c: In function bnx2fc_initiate_cleanup: drivers/scsi/bnx2fc/bnx2fc_io.c:1001:19: warning: variable lport set but not used [-Wunused-but-set-variable] drivers/scsi/bnx2fc/bnx2fc_io.c: In function bnx2fc_process_scsi_cmd_compl: drivers/scsi/bnx2fc/bnx2fc_io.c:1882:20: warning: variable host set but not used [-Wunused-but-set-variable] Reported-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/bnx2fc/bnx2fc_fcoe.c: In function bnx2fc_rcv: drivers/scsi/bnx2fc/bnx2fc_fcoe.c:431:26: warning: variable fh set but not used [-Wunused-but-set-variable] Reported-by:
-
Saurav Kashyap authored
Update the driver version to 8.42.3.0. Signed-off-by:
-
Saurav Kashyap authored
There is a race b/w fipvlan request and response path: ===== qedf_fcoe_process_vlan_resp:113]:2: VLAN response, vid=0xffd. qedf_initiate_fipvlan_req:165]:2: vlan = 0x6ffd already set. qedf_set_vlan_id:139]:2: Setting vlan_id=0ffd prio=3. ====== The request thread sees that vlan is already set and fails to call ctrl_link_up. Fix: - While setting vlan_id use local variable and before setting vlan_id. - Call fcoe_ctlr_link_up in next iteration of fipvlan request. Signed-off-by:
-
Hannes Reinecke authored
The list of rports might become stale so we should rather traverse the discovery list when trying relogin. Signed-off-by:
-
Saurav Kashyap authored
Decrease the LL2 MTU size to 2500. Signed-off-by:
-
Saurav Kashyap authored
Prevent race where we're removing the module and we get link update Signed-off-by:
-
Saurav Kashyap authored
Problem Statement: - Driver has fc_id of 0xcc0200 - Driver gets link down (due to test) and calls fcoe_ctlr_link_down(). - At this point, the fc_id of the initiator port is zeroed out. - Driver gets a link up 14 seconds later. - Driver performs FIP VLAN request, gets a response from the switch. - No change in VLAN is detected. - Driver then notifies libfcoe via fcoe_ctlr_link_up(). - Libfcoe then issues a multicast discovery solicitation as expected. - Cisco FCF responds to that correctly. - Libfcoe at this point starts a 3 sec count-down to allow any other FCFs to be discovered. However, at this point, it has been 20 seconds since the last FKA from the driver (which would have been sent prior to backlink toggle), which causes the CVL to be issued from Cisco CVL from the switch is dropped by the driver as the vx_port identification descriptor is present and has value of 0xcc0200, which does not match the driver's value of 0. Libfcoe completes the 3 sec count down and proceeds to issue FLOGI as per protocol. Switch rejects FLogi request. All subsequent FLOGI requests from libfc are rejected by the switch (possibly because it is now expecting a new solicitation). This situation will continue until the next link toggle. Solution: The Vx_port descriptor in the CVL has three fields: MAC address Fabric ID Port Name Today, the code checks for both #1 and #2 above. In the case where we went through a link down, both these will be zero until FLOGI succeeds. We should change our code to check if any one of these 3 is valid and if so, handle the CVL (basically switching from AND to OR). The port name field is definitely expected to be valid always. Signed-off-by:
-
Saurav Kashyap authored
Log s_id, d_id, type and command to the log message. [mkp: fixed warning] Signed-off-by:
-
Saurav Kashyap authored
The current code doeesn't support 20Gbps speed for current and supported speed. Add support for it. Signed-off-by:
-
Saurav Kashyap authored
Driver was wrongly interpreting the supported cap value returned by qed. Solution: Use QED define macros instead of OS defined for interpreting supporting speeds. Signed-off-by:
-
