- 11 May, 2022 28 commits
-
-
Max Gurtovoy authored
The structure iscsi_cmd naming is used by the iSCSI initiator driver. Rename the target cmd to iscsit_cmd to have more readable code. Link: https://lore.kernel.org/r/20220428092939.36768-1-mgurtovoy@nvidia.comReviewed-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Sreekanth Reddy authored
Complete all new I/O requests issued to an unrecoverable controller with DID_ERROR status instead of returning the I/O requests with SCSI_MLQUEUE_HOST_BUSY. This will prevent the infinite retries of the new I/Os when a controller is in an unrecoverable state. Link: https://lore.kernel.org/r/20220505184808.24049-1-sreekanth.reddy@broadcom.comSigned-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
If any drive is missing during reset, the driver checks whether the device is exposed to the OS. If it is, then it removes the device from the OS and its own internal list. For hidden devices, even if they are found as missing during reset, the driver is not removing them from its internal list. Modify driver to remove hidden devices from the driver's target device list if they are missing during soft reset. Link: https://lore.kernel.org/r/20220505184808.24049-2-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Set each SCSI device's default I/O timeout and default error handling I/O timeout to 60s. Link: https://lore.kernel.org/r/20220505184808.24049-3-sreekanth.reddy@broadcom.comSigned-off-by:
-
James Smart authored
Update lpfc version to 14.2.0.3 Link: https://lore.kernel.org/r/20220506035519.50908-13-jsmart2021@gmail.comCo-developed-by:
Justin Tee <justin.tee@broadcom.com> Signed-off-by:
James Smart <jsmart2021@gmail.com> Signed-off-by:
-
James Smart authored
NVMe I/O problems may be seen on IOMMU enabled platforms. Adapter I/Os failing with transfer length mismatches. The sg list processing routine for NVMe I/O is accessing the sg entry directly for the length and address fields. On some IOMMU platforms, contigous mappings are compressed to the first sg entry with the sum of the lengths set to the sg entry dma_length field. The length fields are left for later use by the unmap call. As such, the driver didn't see the actual dma_length value, just the first entries length value. Drivers are to use the sg_dma_length() and sg_dma_address() macros to reference the sg entry. The macros select the proper length field (dma_length or length) to reference. Fix the offending code to use the sg_dma_xxx macros. Link: https://lore.kernel.org/r/20220506035519.50908-12-jsmart2021@gmail.comTested-by:
Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by:
Nigel Kirkland <nkirkland2304@gmail.com> Signed-off-by:
-
James Smart authored
When configuring CMF management based on signals instead of FPINs, FPIN alarm and warning statistics are not tracked. Change the behavior so that FPIN alarms and warnings are always tracked regardless of the configured mode. Similar changes are made in the CMF signal stat accounting logic. Upon receipt of a signal, only track signaled alarms and warnings. FPIN stats should not be incremented upon receipt of a signal. Link: https://lore.kernel.org/r/20220506035519.50908-11-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
After a link up, it's possible for the switch to change FDMI support (e.g. FDMI1 vs FDMI2 vs SmartSAN). If the switch reverts to FDMI1, then the revert is currently not detected. Additionally, when NPIV is configured, it's possible the physical port's RHBA is unprocessed by the switch before reciept of an NPIV port issued RPRT. This causes some switches vendors to reject the NPIV's RPRT. Fix by reinitializing base FDMI mode on link up, and defer FDMI vport RPRT submission until after confirming physical port's RHBA is completed. Link: https://lore.kernel.org/r/20220506035519.50908-10-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Currently, VMID registration is configured via module parameters. This could lead to VMID compatibility issues if two ports are connected to different brands of switches, as the two brands implement VMID differently. Make logical changes so that VMID registration is based on common service parameters from FLOGI_ACC with fabric rather than module parameters. Link: https://lore.kernel.org/r/20220506035519.50908-9-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
During large NPIV port testing, it was sometimes seen that not all vports would log back in to the target device. There are instances when the fabric is slow to respond to a spam of GID_PT requests and as a result the SLI PORT may abort the GID_PT request because the fabric takes so long. lpfc_cmpl_ct_cmd_gid_pt() would enter the lpfc_err_lost_link() logic and attempt to lpfc_els_flush_rscn(), which is fine, but forgets to decrement the gidft_inp counter. This results in a vport->gidft_inp never reaching 0 and never restarting discovery again. Decrement vport->gidft_inp if lpfc_err_lost_link() is true for both lpfc_cmpl_ct_cmd_gid_pt() and lpfc_cmpl_ct_cmd_gid_ft(). Increase logging info during RSCN timeout and lpfc_err_lost_link() events. Link: https://lore.kernel.org/r/20220506035519.50908-8-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
In GID_PT mode with lpfc_ns_query=1, a race condition between iterating the vport->fc_nodes list in lpfc_rscn_recovery_check() and cleanup of an ndlp can trigger a crash while processing the RSCN of another initiator from the same zone. During iteration of the vport->fc_nodes list, an ndlp is cleaned up and released. lpfc_dequeue_node() is called from lpfc_cleanup_node() leading to a bad ndlp dereference in lpfc_rscn_recovery_check(). Change list_for_each_entry() to list_for_each_entry_safe() in lpfc_rscn_recovery_check() to protect against removal of an initiator ndlp, while walking the vport->fc_nodes list. Link: https://lore.kernel.org/r/20220506035519.50908-7-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Upon driver receipt of a CT cmd for type = 0xFA (Management Server) and subtype = 0x11 (Fabric Device Management Interface), the driver is responding with garbage CT cmd data when it should send a properly formed RJT. The __lpfc_prep_xmit_seq64_s4() routine was using the wrong buffer for the reject. Fix by converting the routine to use the buffer specified in the bde within the wqe rather than the ill-set bmp element. Link: https://lore.kernel.org/r/20220506035519.50908-6-jsmart2021@gmail.com Fixes: 61910d6a ("scsi: lpfc: SLI path split: Refactor CT paths") Co-developed-by:
-
James Smart authored
After running a short external loopback test, when the external loopback is removed and a normal cable inserted that is directly connected to a target device, the system oops in the llpfc_set_rrq_active() routine. When the loopback was inserted an FLOGI was transmit. As we're looped back, we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same wppn thus understand it's a loopback. However, as the ABTS sends address information the port is not set to (fffffe), the ABTS is dropped on the wire. A short 1 frame loopback test is run and completes before the ABTS times out. The looback is unplugged and the new cable plugged in, and the an FLOGI to the new device occurs and completes. Due to a mixup in ref counting the completion of the new FLOGI releases the fabric ndlp. Then the original ABTS completes and references the released ndlp generating the oops. Correct by no-op'ing the ABTS when in loopback mode (it will be dropped anyway). Added a flag to track the mode to recognize when it should be no-op'd. Link: https://lore.kernel.org/r/20220506035519.50908-5-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
During testing with repeated asynchronous resets of the target, an issue was found when the driver issues a LOGO to disconnect its login and recover all exchanges. The LOGO command takes a node reference but neglects to remove it, keeping the node reference count artifically high. Add a call to lpfc_nlp_put() to lpfc_nlp_logo_unreg() and move the mempool free call to the routine exit along with the needed put. This is always safe as this will not be the last reference removed as lpfc_unreg_rpi() ensures there is an additional reference on the ndlp. Link: https://lore.kernel.org/r/20220506035519.50908-4-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
Code review, following every lpfc_nlp_get() call vs calls during error handling, discovered cases of missing put calls. Correct by adding ndlp kref puts in the respective error paths. Also added comments to several of the error paths to record relationships to reference counts. Link: https://lore.kernel.org/r/20220506035519.50908-3-jsmart2021@gmail.comCo-developed-by:
-
James Smart authored
The prior commit that moved from iocb elements to explicit wqe elements missed a name change. Correct __lpfc_sli_release_iocbq_s4() to reference wqe rather than iocb. Link: https://lore.kernel.org/r/20220506035519.50908-2-jsmart2021@gmail.com Fixes: a680a929 ("scsi: lpfc: SLI path split: Refactor lpfc_iocbq") Co-developed-by:
-
Bean Huo authored
ufshpb_resume() is only called when the HPB state is HPB_SUSPEND, so the check statement for "ufshpb_get_state(hpb) != HPB_PRESENT" is useless. Link: https://lore.kernel.org/r/20220505134707.35929-7-huobean@gmail.comReviewed-by:
Keoseong Park <keosung.park@samsung.com> Signed-off-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Bean Huo authored
In UFS HPB Spec JESD220-3A, "5.8. Active and inactive information upon power cycle ... When the device is powered off by the host, the device may restore L2P map data upon power up or build from the host's HPB READ command. In case device powered up and lost HPB information, device can signal to the host through HPB Sense data, by setting HPB Operation as '2' which will inform the host that device reset HPB information." Therefore, for HPB device control mode, if the UFS device is reset via the RST_N pin, the active region information in the device will be reset. If the host side receives this notification from the device side, it is recommended to inactivate all active regions in the host's HPB cache. Link: https://lore.kernel.org/r/20220505134707.35929-6-huobean@gmail.comReviewed-by:
Daejun Park <daejun7.park@samsung.com> Signed-off-by:
-
Bean Huo authored
According to the documentation of the sysfs nodes rb_noti_cnt, rb_active_cnt and rb_inactive_cnt, these are all related to HPB recommendation in UPIU response packet. 'rcmd' (recommendation) should be the correct abbreviation. Change the sysfs documentation about these sysfs nodes to highlight what they mean under different HPB control modes. Link: https://lore.kernel.org/r/20220505134707.35929-5-huobean@gmail.comReviewed-by:
-
Bean Huo authored
"When the device is powered off by the host, the device may restore L2P map data upon power up or build from the host's HPB READ command. In case device powered up and lost HPB information, device can signal to the host through HPB Sense data, by setting HPB Operation as '2' which will inform the host that device reset HPB information." Clean up the handler and make the intent of this handler more readable, no functional change. Link: https://lore.kernel.org/r/20220505134707.35929-4-huobean@gmail.comReviewed-by:
-
Bean Huo authored
If the first enumerator has no initializer, the value of the corresponding constant is zero. Link: https://lore.kernel.org/r/20220505134707.35929-3-huobean@gmail.comReviewed-by:
-
Bean Huo authored
There is no functional change in this patch, just merge ufshpb_reset() and ufshpb_reset_host() into one function ufshpb_toggle_state(). Link: https://lore.kernel.org/r/20220505134707.35929-2-huobean@gmail.comReviewed-by:
-
Manivannan Sadhasivam authored
In order to allow the block devices to enter autosuspend mode during runtime, thereby allowing the ufshcd host driver to also runtime suspend, let's make use of the RPM_AUTOSUSPEND flag. Without this flag, userspace needs to enable the autosuspend feature of the block devices through sysfs. Link: https://lore.kernel.org/r/20220504084212.11605-6-manivannan.sadhasivam@linaro.orgReviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Manivannan Sadhasivam authored
The wmb() inside ufshcd_send_command() is added to make sure that the doorbell is committed immediately. This leads to couple of expectations: 1. The doorbell write should complete before the function return. 2. The doorbell write should not cross the function boundary. 2nd expectation is fullfilled by the Linux memory model as there is a guarantee that the critical section won't cross the unlock (release) operation. 1st expectation is not really needed here as there is no following read/ write that depends on the doorbell to be complete implicitly. Even if the doorbell write is in a CPUs Write Buffer (WB), wmb() won't flush it. And there is no real need of a WB flush here as well. So let's get rid of the wmb() that seems redundant. Link: https://lore.kernel.org/r/20220504084212.11605-5-manivannan.sadhasivam@linaro.orgReviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
-
Manivannan Sadhasivam authored
In ufs_qcom_dev_ref_clk_ctrl(), it was noted that the ref_clk needs to be stable for at least 1us. Even though there is wmb() to make sure the write gets "completed", there is no guarantee that the write actually reached the UFS device. There is a good chance that the write could be stored in a Write Buffer (WB). In that case, even though the CPU waits for 1us, the ref_clk might not be stable for that period. So lets do a readl() to make sure that the previous write has reached the UFS device before udelay(). Also, the wmb() after writel_relaxed() is not really needed. Both writel() and readl() are ordered on all architectures and the CPU won't speculate instructions after readl() due to the in-built control dependency with read value on weakly ordered architectures. So it can be safely removed. Link: https://lore.kernel.org/r/20220504084212.11605-4-manivannan.sadhasivam@linaro.org Fixes: f06fcc71 ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Cc: stable@vger.kernel.org Reviewed-by:
-
Manivannan Sadhasivam authored
There is no need to call devm_phy_get() if ACPI is used, so skip it. The host->generic_phy pointer should already be NULL due to the kzalloc(), so no need to set it NULL again. While at it, also remove the comment that has no relationship with devm_phy_get(). Link: https://lore.kernel.org/r/20220504084212.11605-3-manivannan.sadhasivam@linaro.orgReviewed-by:
Andrew Halaney <ahalaney@redhat.com> Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom UFS platforms, the reset control line seems to be optional (for SoCs like MSM8996 and probably for others too). The current logic tries to mimic the devm_reset_control_get_optional() API but it also continues the probe if there is an error with the declared reset line in DT/ACPI. In an ideal case, if the reset line is not declared in DT/ACPI, the probe should continue. But if there is problem in acquiring the declared reset line (like EPROBE_DEFER) it should fail and return the appropriate error code. Link: https://lore.kernel.org/r/20220504084212.11605-2-manivannan.sadhasivam@linaro.orgReviewed-by:
-
Xiang Chen authored
If we fail to notify the phy up event then undo the RPM resume, as the phy up notify event handling pairs with that RPM resume. Link: https://lore.kernel.org/r/1651839939-101188-1-git-send-email-john.garry@huawei.comReported-by:
Yihang Li <liyihang6@hisilicon.com> Tested-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
- 02 May, 2022 12 commits
-
-
Sumit Saxena authored
Link: https://lore.kernel.org/r/20220429211641.642010-9-sumit.saxena@broadcom.comSigned-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Sumit Saxena authored
Add support for management applications to send an MPI3 Encapsulated NVMe passthru command to the NVMe devices attached to an Avenger controller. Since the NVMe drives are exposed as SCSI devices by the controller, the standard NVMe applications cannot be used to interact with the drives and the command sets supported are also limited by the controller firmware. Special handling is required for MPI3 Encapsulated NVMe passthru commands for PRP/SGL setup in the commands. Link: https://lore.kernel.org/r/20220429211641.642010-8-sumit.saxena@broadcom.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
-
Sumit Saxena authored
Link: https://lore.kernel.org/r/20220429211641.642010-7-sumit.saxena@broadcom.comReviewed-by:
-
Sumit Saxena authored
Implement driver support for management applications to enable persistent event log (PEL) notifications. Upon receipt of events, the driver will increment a sysfs variable named event_counter. The management application will poll for event_counter value changes and signal the application about events. Link: https://lore.kernel.org/r/20220429211641.642010-6-sumit.saxena@broadcom.comReviewed-by:
-
Sumit Saxena authored
There are certain management commands which require firmware intervention. These commands are termed MPT commands. Add support for them. Link: https://lore.kernel.org/r/20220429211641.642010-5-sumit.saxena@broadcom.comReviewed-by:
-
Sumit Saxena authored
This patch moves the data structures/definitions which are used by userspace applications from MPI headers to uapi/scsi/scsi_bsg_mpi3mr.h Link: https://lore.kernel.org/r/20220429211641.642010-4-sumit.saxena@broadcom.com Reported by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
-
Sumit Saxena authored
There are certain bsg commands which need to be completed by the driver without involving firmware. These requests are termed driver commands. Add support for these. Link: https://lore.kernel.org/r/20220429211641.642010-3-sumit.saxena@broadcom.com Reported by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Sumit Saxena authored
Create bsg device per controller for controller management purposes. bsg device nodes will be named /dev/bsg/mpi3mrctl0, /dev/bsg/mpi3mrctl1, etc. Link: https://lore.kernel.org/r/20220429211641.642010-2-sumit.saxena@broadcom.comReported-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
-
Enze Li authored
The function get_capabilities() has the possibility of failing to allocate the transfer buffer but it does not currently handle this. This may lead to exceptions when accessing the buffer. Add error handling when memory allocation fails. Link: https://lore.kernel.org/r/20220427025647.298358-1-lienze@kylinos.cnSigned-off-by:
Enze Li <lienze@kylinos.cn> Signed-off-by:
-
Xiaoguang Wang authored
When tcmu_vma_fault() gets a page successfully, before the current context completes page fault procedure, find_free_blocks() may run and call unmap_mapping_range() to unmap the page. Assume that when find_free_blocks() initially completes and the previous page fault procedure starts to run again and completes, then one truncated page has been mapped to userspace. But note that tcmu_vma_fault() has gotten a refcount for the page so any other subsystem won't be able to use the page unless the userspace address is unmapped later. If another command subsequently runs and needs to extend dbi_thresh it may reuse the corresponding slot for the previous page in data_bitmap. Then though we'll allocate new page for this slot in data_area, no page fault will happen because we have a valid map and the real request's data will be lost. Filesystem implementations will also run into this issue but they usually lock the page when vm_operations_struct->fault gets a page and unlock the page after finish_fault() completes. For truncate filesystems lock pages in truncate_inode_pages() to protect against racing wrt. page faults. To fix this possible data corruption scenario we can apply a method similar to the filesystems. For pages that are to be freed, tcmu_blocks_release() locks and unlocks. Make tcmu_vma_fault() also lock found page under cmdr_lock. At the same time, since tcmu_vma_fault() gets an extra page refcount, tcmu_blocks_release() won't free pages if pages are in page fault procedure, which means it is safe to call tcmu_blocks_release() before unmap_mapping_range(). With these changes tcmu_blocks_release() will wait for all page faults to be completed before calling unmap_mapping_range(). And later, if unmap_mapping_range() is called, it will ensure stale mappings are removed. Link: https://lore.kernel.org/r/20220421023735.9018-1-xiaoguang.wang@linux.alibaba.comReviewed-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by:
-
James Smart authored
Prior patch added a call to lpfc_sli_prep_wqe() prior to lpfc_sli_issue_iocb(). This call should not have been added as prep_wqe is called within the issue_iocb routine. So it's called twice now. Remove the redundant prep call. Link: https://lore.kernel.org/r/20220427222223.57920-1-jsmart2021@gmail.com Fixes: 31a59f75 ("scsi: lpfc: SLI path split: Refactor Abort paths") Signed-off-by:
-
James Smart authored
Code inspection has found an additional reference is taken in lpfc_bsg_rport_els(). Results in the ndlp not being freed thus is leaked. Fix by removing the redundant refcount taken before WQE submission. Link: https://lore.kernel.org/r/20220427222158.57867-1-jsmart2021@gmail.comCo-developed-by:
Nigel Kirkland <nigel.kirkland@broadcom.com> Signed-off-by:
-
