- 29 Aug, 2019 37 commits
-
-
Saurav Kashyap authored
Update the driver version to 8.42.3.0. Signed-off-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
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:
Hannes Reinecke <hare@suse.com> 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:
-
Saurav Kashyap authored
Add shutdown callback handler. Signed-off-by:
-
Nilesh Javali authored
Update module description. Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Arun Easi authored
Driver was attempting to print cdb[0], which is not set for resets coming from SCSI ioctls. Check for cmd_len before accessing cmnd. Crash info: [84790.864747] BUG: unable to handle kernel NULL pointer dereference at (null) [84790.864783] IP: qedf_initiate_tmf+0x7a/0x6e0 [qedf] [84790.865204] Call Trace: [84790.865246] scsi_try_target_reset+0x2b/0x90 [scsi_mod] [84790.865266] scsi_ioctl_reset+0x20f/0x2a0 [scsi_mod] [84790.865284] scsi_ioctl+0x131/0x3a0 [scsi_mod] Signed-off-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Saurav Kashyap authored
- On some setups fipvlan can be retried for long duration and the connection to switch was not there so it was not getting any reply. - During unload this thread was hanging. Problem Resolution: Check if unload is in progress, then quit from fipvlan thread. Signed-off-by:
-
Saurav Kashyap authored
Print messages during exiting condition to help debugging. Signed-off-by:
-
Don Brace authored
Reviewed-by:
Scott Benesh <scott.benesh@microsemi.com> Reviewed-by:
Gerry Morong <gerry.morong@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Don Brace authored
Reviewed-by:
Kevin Barnett <kevin.barnett@microsemi.com> Signed-off-by:
-
Gilbert Wu authored
Add: PM8222 VID_9005, DID_028F, SVID_1BD4 and SDID_004F 3101E-4i (1G, no GB) VID_9005, DID_028F, SVID_9005 and SDID_0808 3102E-8i (2G, no GB) VID_9005, DID_028F, SVID_9005 and SDID_0809 Reviewed-by:Gilbert Wu <gilbert.wu@microsemi.com> Signed-off-by:
-
Murthy Bhat authored
Return -EINPROGRESS when a rescan worker is queued. Reviewed-by:
Murthy Bhat <Murthy.Bhat@microsemi.com> Signed-off-by:
-
Gilbert Wu authored
Reviewed-by:
-
Mahesh Rajashekhara authored
When each ld is deleted, a rescan event is triggered in the driver. These can stack up waiting on mutex_lock. Change to mutex_try_lock and schedule a rescan for later. Reviewed-by:
Mahesh Rajashekhara <mahesh.rajashekhara@microsemi.com> Signed-off-by:
-
Gilbert Wu authored
Return identify physical device "Phys_Bay_in_Box" as bay_identifier. Reviewed-by:
-
Murthy Bhat authored
- serial number - model - vendor Reviewed-by:
-
Dave Carroll authored
Reviewed-by:
Dave Carroll <david.carroll@microsemi.com> Signed-off-by:
-
Gilbert Wu authored
Reviewed-by:
-
Gilbert Wu authored
Expose physical devices before logical devices. Reviewed-by:
-
James Smart authored
The 12.4.0.0 patch that merged WQ/CQ pairs into single per-cpu pair contained a bug: a local variable was set to the queue pair by index. This should have allowed the local variable to be natively used. Instead, the code reused the index relative to the local variable, obtaining a random pointer value that when used eventually faulted the system Convert offending code to use local variable. Fixes: c00f62e6 ("scsi: lpfc: Merge per-protocol WQ/CQ pairs into single per-cpu pair") Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Tested-by:
Abdul Haleem <abdhalee@linux.vnet.ibm.com> Signed-off-by:
-
James Smart authored
Capturing and downloading dif command data and dif data was done a dozen years ago and no longer being used. Also creates a potential security hole. Remove the debugfs buffer for dif debugging. Signed-off-by:
-
James Smart authored
Per Dan Carpenter: The patch d79c9e9d: "scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware." from Aug 14, 2019, leads to the following static checker warning: drivers/scsi/lpfc/lpfc_init.c:4107 lpfc_new_io_buf() error: not allocating enough data 784 vs 768 There was no need to compare sizes nor to allocate size based on a define. Change allocation to use actual structure length Signed-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/ufs/ufs-qcom.c: In function ufs_qcom_pwr_change_notify: drivers/scsi/ufs/ufs-qcom.c:808:6: warning: variable val set but not used [-Wunused-but-set-variable] Fixes: 1e1e465c ("scsi/ufs: qcom: Remove ufs_qcom_phy_*() calls from host") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
zhengbin <zhengbin13@huawei.com> Acked-by:
Avri Altman <Avri.Altman@wdc.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a ql_log message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
zhengbin authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/hisi_sas/hisi_sas_v1_hw.c: In function cq_interrupt_v1_hw: drivers/scsi/hisi_sas/hisi_sas_v1_hw.c:1542:6: warning: variable irq_value set but not used [-Wunused-but-set-variable] Reported-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Sreekanth Reddy authored
This patch provides a module parameter and sysfs interface to select whether the queue depth for each device should be based on the protocol-specific value set by the driver (the default) or the maximum supported by the controller (can_queue). Although we have a sysfs interface per sdev to change the queue depth of individual scsi devices, this implementation provides a single sysfs entry per shost to switch between the controller max and the driver default. [mkp: tweaked commit desc] Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Bart Van Assche authored
According to the firmware documentation a status type 0 IOCB can be followed by one or more status continuation type 0 IOCBs. Hence do not complain if the completion function is not called from inside the status type 0 IOCB handler. WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784 qla2x00_status_entry.isra.7+0x484/0x17b0 [qla2xxx] CPU: 10 PID: 425 Comm: kworker/10:1 Tainted: G E 5.3.0-rc4-next-20190813-autotest-autotest #1 Workqueue: qla2xxx_wq qla25xx_free_rsp_que [qla2xxx] Call Trace: qla2x00_status_entry.isra.7+0x1484/0x17b0 [qla2xxx] (unreliable) qla24xx_process_response_queue+0x7d8/0xbd0 [qla2xxx] qla25xx_free_rsp_que+0x1a0/0x220 [qla2xxx] process_one_work+0x25c/0x520 worker_thread+0x8c/0x5e0 kthread+0x154/0x1a0 ret_from_kernel_thread+0x5c/0x7c Cc: Himanshu Madhani <hmadhani@marvell.com> Cc: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Reported-by:
Bart Van Assche <bvanassche@acm.org> Tested-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
-
Stanley Chu authored
Currently bits in hba->outstanding_tasks are cleared only after their corresponding task management commands are successfully done by __ufshcd_issue_tm_cmd(). If timeout happens in a task management command, its corresponding bit in hba->outstanding_tasks will not be cleared until next task management command with the same tag used successfully finishes. This is wrong and can lead to some issues, like power issue. For example, ufshcd_release() and ufshcd_gate_work() will do nothing if hba->outstanding_tasks is not zero even if both UFS host and devices are actually idle. Solution is referred from error handling of device commands: bits in hba->outstanding_tasks shall be cleared regardless of their execution results. Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
Chun-Hung Wu <chun-hung.wu@mediatek.com> Reviewed-by:
-
Colin Ian King authored
Pointer fh is being assigned a return value from the call to skb_transport_header however this value is never read and fh is being re-assigned immediately afterwards with a new value. Since there are side-effects from calling skb_transport_header the call is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: -
Anil Varughese authored
Some UFS devices have issues if LCC is enabled. So we are setting PA_LOCAL_TX_LCC_Enable to 0 before link startup which will make sure that both host and device TX LCC are disabled once link startup is completed. Signed-off-by:
Anil Varughese <aniljoy@cadence.com> Reviewed-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Colin Ian King authored
Variable error is being initialized with a value that is never read and error is being re-assigned a little later on. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:
-
- 20 Aug, 2019 3 commits
-
-
James Smart authored
Update lpfc version to 12.4.0.0 Signed-off-by:
-
James Smart authored
Currently, each hardware queue, typically allocated per-cpu, consists of a WQ/CQ pair per protocol. Meaning if both SCSI and NVMe are supported 2 WQ/CQ pairs will exist for the hardware queue. Separate queues are unnecessary. The current implementation wastes memory backing the 2nd set of queues, and the use of double the SLI-4 WQ/CQ's means less hardware queues can be supported which means there may not always be enough to have a pair per cpu. If there is only 1 pair per cpu, more cpu's may get their own WQ/CQ. Rework the implementation to use a single WQ/CQ pair by both protocols. Signed-off-by:
-
James Smart authored
FC-NVMe-2 added support for sequence level error recovery in the FC-NVME protocol. This allows for the detection of errors and lost frames and immediate retransmission of data to avoid exchange termination, which escalates into NVMeoFC connection and association failures. A significant RAS improvement. The driver is modified to indicate support for SLER in the NVMe PRLI is issues and to check for support in the PRLI response. When both sides support it, the driver will set a bit in the WQE to enable the recovery behavior on the exchange. The adapter will take care of all detection and retransmission. Signed-off-by:
-
