- 20 Nov, 2020 17 commits
-
-
Colin Ian King authored
There is a null check on pointer lpfc_cmd after the pointer has been dereferenced when pointers rdata and ndlp are initialized at the start of the function. Fix this by only assigning rdata and ndlp after the pointer lpfc_cmd has been null checked. Link: https://lore.kernel.org/r/20201118131345.460631-1-colin.king@canonical.com Fixes: 96e209be ("scsi: lpfc: Convert SCSI I/O completions to SLI-3 and SLI-4 handlers") Reviewed-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Addresses-Coverity: ("Dereference before null check")
-
Tyrel Datwyler authored
The previous patch added support for the targetWWPN field in version 2 MADs and vfcFrame structures. Set the IBMVFC_CAN_SEND_VF_WWPN bit in our capabailites flag during NPIV Login to inform the VIOS that this client supports the feature. Link: https://lore.kernel.org/r/20201118011104.296999-7-tyreld@linux.ibm.comAcked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
-
Tyrel Datwyler authored
Several version 2 MADs and the version 2 vfcFrame structures introduced a new targetWWPN field for better identification of a target over the scsi_id. Set this field and MAD versioning fields when the VIOS advertises the IBMVFC_HANDLE_VF_WWPN capability. Link: https://lore.kernel.org/r/20201118011104.296999-6-tyreld@linux.ibm.comAcked-by:
-
Tyrel Datwyler authored
The FC iu and response payloads are located at different offsets depending on the ibmvfc_cmd version. This is a result of the version 2 vfcFrame definition adding an extra 64bytes of reserved space to the structure prior to the payloads. Add helper routines to determine the current vfcFrame version and return a pointer to the proper iu or response structure within that ibmvfc_cmd. Link: https://lore.kernel.org/r/20201118011104.296999-5-tyreld@linux.ibm.comAcked-by:
-
Tyrel Datwyler authored
Testing the NPIV Login response capabilities is a long winded process of dereferencing the vhost->login_buf->resp.capabilities field, then byte swapping that value to host endian, and performing the bitwise test. Currently we only ever check this in ibmvfc_cancel_all(), but follow-up patches will need to regularly check for targetWWPN and channelization support. Add a helper to simplify checking various VIOS capabilities, namely ibmvfc_check_caps(). Link: https://lore.kernel.org/r/20201118011104.296999-4-tyreld@linux.ibm.comAcked-by:
-
Tyrel Datwyler authored
Introduce a target_wwpn field to several MADs. Its possible that a SCSI ID of a target can change due to some fabric changes. The WWPN of the SCSI target provides a better way to identify the target. Also, add flags for receiving MAD versioning information and advertising client support for targetWWPN with the VIOS. This latter capability flag will be required for future clients capable of requesting multiple hardware queues from the host adapter. Link: https://lore.kernel.org/r/20201118011104.296999-3-tyreld@linux.ibm.comAcked-by:
-
Tyrel Datwyler authored
The virtual FC frame command exchanged with the VIOS is used for device reset and command abort TMF as well as normally queued commands. When initializing the ibmvfc_cmd there are several elements of the command that are set the same way regardless of the command type. Deduplicate code by moving these commonally set fields into a initialization helper routine, namely ibmvfc_init_vfc_cmd(). Link: https://lore.kernel.org/r/20201118011104.296999-2-tyreld@linux.ibm.comAcked-by:
-
Tyrel Datwyler authored
The vfcFrame correlation field is a 64bit handle that is intended to trace I/O operations through both the client stack and VIOS stack when the underlying physical FC adapter supports tagging. Tag vfcFrames with the associated ibmvfc_event pointer handle. Link: https://lore.kernel.org/r/20201117185031.129939-3-tyreld@linux.ibm.comSigned-off-by:
-
Tyrel Datwyler authored
Remove a superfluous semicolon following a closing function block bracket. Link: https://lore.kernel.org/r/20201117185031.129939-2-tyreld@linux.ibm.comSigned-off-by:
-
Tyrel Datwyler authored
Both ibmvfc_show_host_(capabilities|npiv_version) functions retrieve values from vhost->login_buf.resp buffer. This is the MAD response buffer from the VIOS and as such any multi-byte non-string values are in big endian format. Byte swap these values to host CPU endian format for better human readability. Link: https://lore.kernel.org/r/20201117185031.129939-1-tyreld@linux.ibm.comSigned-off-by:
-
Leo Liou authored
We have LBA and length for unmap commands. Link: https://lore.kernel.org/r/20201117165839.1643377-8-jaegeuk@kernel.orgReviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Leo Liou <leoliou@google.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Jaegeuk Kim authored
The following call stack prevents clk_gating at every I/O completion. We can remove the condition, ufshcd_any_tag_in_use(), since clkgating_work will check it again. ufshcd_complete_requests(struct ufs_hba *hba) ufshcd_transfer_req_compl() __ufshcd_transfer_req_compl() __ufshcd_release(hba) if (ufshcd_any_tag_in_use() == 1) return; ufshcd_tmc_handler(hba); blk_mq_tagset_busy_iter(); Note that this still requires work to deal with a potential race condition when user sets clkgating.delay_ms to very small value. That can cause preventing clkgating by the check of ufshcd_any_tag_in_use() in gate_work. Link: https://lore.kernel.org/r/20201117165839.1643377-7-jaegeuk@kernel.org Fixes: 7252a360 ("scsi: ufs: Avoid busy-waiting by eliminating tag conflicts") Reviewed-by:Asutosh Das <asutoshd@codeaurora.org> Reviewed-by:
-
Jaegeuk Kim authored
This adds user-friendly tracepoints with group id. Link: https://lore.kernel.org/r/20201117165839.1643377-6-jaegeuk@kernel.orgReviewed-by:
Jaegeuk Kim <jaegeuk@google.com> Signed-off-by:
-
Jaegeuk Kim authored
Must have WQ_MEM_RECLAIM ``WQ_MEM_RECLAIM`` All workqueues which might be used in the memory reclaim paths **MUST** have this flag set. The wq is guaranteed to have at least one execution context regardless of memory pressure. Link: https://lore.kernel.org/r/20201117165839.1643377-5-jaegeuk@kernel.orgReviewed-by:
-
Jaegeuk Kim authored
In order to conduct FFU or RPMB operations, UFS needs to clear UNIT ATTENTION condition. Clear it explicitly so that we get no failures during initialization. Link: https://lore.kernel.org/r/20201117165839.1643377-4-jaegeuk@kernel.orgSigned-off-by:
-
Jaegeuk Kim authored
While running a stress test which enables/disables clkgating, we occasionally hit device timeout. This patch avoids a subtle race condition to address it. Link: https://lore.kernel.org/r/20201117165839.1643377-3-jaegeuk@kernel.orgReviewed-by:
-
Jaegeuk Kim authored
Once UFS is gated with CLKS_OFF, it should not call REQ_CLKS_OFF again. This can lead to hibern8_enter failure. Link: https://lore.kernel.org/r/20201117165839.1643377-2-jaegeuk@kernel.orgReviewed-by:
-
- 17 Nov, 2020 23 commits
-
-
Jing Xiangfeng authored
The variable rval has been initialized with 'QLA_ERROR'. The assignment is redundant in an error path. Remove it. Link: https://lore.kernel.org/r/20201103120137.109717-1-jingxiangfeng@huawei.comSigned-off-by:
Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by:
-
Stanley Chu authored
Use common ADAPT configuration function to reduce duplicated code in UFS drivers. Link: https://lore.kernel.org/r/20201116065054.7658-10-stanley.chu@mediatek.comReviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Stanley Chu authored
Use common ADAPT configuration function to reduce duplicated code in UFS drivers. Link: https://lore.kernel.org/r/20201116065054.7658-9-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Several vendors are using same code to configure ADAPT settings for HS-G4. Simply refactor it as common function. Link: https://lore.kernel.org/r/20201116065054.7658-8-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Use common device parameter initialization function instead of initializing those parameters by vendor driver itself. Link: https://lore.kernel.org/r/20201116065054.7658-7-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Use common device parameter initialization function instead of initializing those parameters by vendor driver itself. Link: https://lore.kernel.org/r/20201116065054.7658-6-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Use common device parameter initialization function instead of initializing those parameters by vendor driver itself. Link: https://lore.kernel.org/r/20201116065054.7658-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Use common device parameter initialization function instead of initializing those parameters by vendor driver itself. Link: https://lore.kernel.org/r/20201116065054.7658-4-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Nowadays many vendors initialize their device parameters in their own vendor drivers. The initialization code is almost the same as well as the pre-defined definitions. Introduce a common device parameter initialization function which assign the most common initial values. With this function, we could remove those duplicated codes in vendor drivers. Link: https://lore.kernel.org/r/20201116065054.7658-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Refactor performance scaling related functions in MediaTek UFS driver. Link: https://lore.kernel.org/r/20201116065054.7658-2-stanley.chu@mediatek.comReviewed-by:
-
James Smart authored
Update Copyright in files changed by the 12.8.0.6 patch set to 2020 Link: https://lore.kernel.org/r/20201115192646.12977-18-james.smart@broadcom.comCo-developed-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
James Smart authored
Update lpfc version to 12.8.0.6 Link: https://lore.kernel.org/r/20201115192646.12977-17-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
This patch reworks the abort interfaces such that SLI-3 retains the iocb-based formatting and completions and SLI-4 now uses native WQEs and completion routines. The following changes are made: - The code is refactored from a confusing 2 routine sequence of xx_abort_iotag_issue(), which creates/formats and abort cmd, and xx_issue_abort_tag(), which then issues and handles the completion of the abort cmd - into a single interface of xx_issue_abort_iotag(). The new interface will determine whether SLI-3 or SLI-4 and then call the appropriate handler. A completion handler can now be specified to address the differences in completion handling. Note: original code is all iocb based, with SLI-4 converting to SLI-3 for the SCSI/ELS path, and NVMe natively using wqes. - The SLI-3 side is refactored: The older iocb-base lpfc_sli_issue_abort_iotag() routine is combined with the logic of lpfc_sli_abort_iotag_issue() as well as the iocb-specific code in lpfc_abort_handler() and lpfc_sli_abort_iocb() to create the new single SLI-3 abort routine that formats and issues the iocb. - The SLI-4 side is refactored and added to: The native WQE abort code in NVMe is moved to the new SLI-4 issue_abort_iotag() routine. Items in SCSI that set fields not set by NVMe is migrated into the new routine. Thus the routine supports NVMe and SCSI initiators. The nvmet block (target) formats the abort slightly different (like the old NVMe initiator) thus it has its own prep routine stolen from NVMe initiator and it retains the current code it has for issuing the WQE (does not use the commonized routine the initiators do). SLI-4 completion handlers were also added. - lpfc_abort_handler now becomes a wrapper that determines whether SLI-3 or SLI-4 and calls the proper abort handler. Link: https://lore.kernel.org/r/20201115192646.12977-16-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
The current driver implementation uses SLI-4 WQE to iocb conversion before calling the cmpl callback function. Rework the FCP I/O completion path to utilize the SLI-4 WQE. This patch converts the SCSI I/O completion paths from the iocb-centric interfaces to the routines are native for whether I/Os are iocb-based (SLI-3) or WQE-based (SLI-4). Most existing routines were iocb-based, so this creates a lot of SLI-4 specific routines to provide the functionality. Link: https://lore.kernel.org/r/20201115192646.12977-15-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
This patch converts the SCSI I/O path from the iocb-centric interfaces to the common I/O submission path which supports native SLI-4 WQEs. A wrapper routine is put in place to distinguish SLI-3 from SLI. If SLI-3, the same iocb-centric paths are used, perhaps with refactored code that is explicitly for SLI-3. For SLI-4, any iocb-related formatting is replaced by wqe-based formatting, although much of that is addressed by the common wqe templates in the SLI-4 path. Link: https://lore.kernel.org/r/20201115192646.12977-14-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
To set up common use by the SCSI and NVMe I/O paths, create a new routine that issues FCP I/O commands which can be used by either protocol. The new routine addresses SLI-3 vs SLI-4 differences within its implementation. Replace the (SLI-3 centric) iocb routine in the SCSI path with this new WQE-centric common routine. Link: https://lore.kernel.org/r/20201115192646.12977-13-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
The driver is currently using SLI-4 WQE templates only for NVMe. Refactor the template and the placement of the service routine so that it can be used by both SCSI and NVMe. Link: https://lore.kernel.org/r/20201115192646.12977-12-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
In preparation of reworking the driver to use a native SLI-4 WQE interface for the SCSI and NVMe I/O paths, start by commonizing the WQE exchange type and command type attributes. While adjusting these options also noted the variance in the pbde field. Fix this by setting templates to 0 and in NVMe, which explicitly uses this option, setting the value. Link: https://lore.kernel.org/r/20201115192646.12977-11-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
While testing initiator-side cable swaps with NPIV, oops occur. The reference counts for the Fabric nodes on the NPIV vports isn't balanced, resulting in premature node removal. The following fixes were made: - Removed the FC_LBIT check in lpfc_linkup_port. This removed the special case for vports that didn't have them clean up just like the physical port. - Removed the unreg_rpi call in lpfc_cleanup_node. In this section, the node is being removed in the context of a reference count release and a mailbox command can't be issued at this point. - Remove special case handling in the default mailbox completion handler that allowed the skipping of a node reference. Now, reference counting always requires the removal of the reference. - Move the location of the DEVICE_RM event is done during LOGO handling as the driver has additional work to do on the ndlp before puts/releases can be performed. Link: https://lore.kernel.org/r/20201115192646.12977-10-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
While testing NPIV and link bounces, the vport would not show a fabric node for the F_Port, would not transition into NPR state during a link fault, or leave the FDMI node untouched during error injection. Cause for this was determined to be an inconsistent manner in which F_Port, Nameserver, and FDMI controller nodes were created and linked. In some cases, the nodes would never be unregistered from the transport, leaving references active. In other cases, the fabric nodes may register with the transport multiple times while still registered. The following changes were made: - Fix the FDISC issue routine, which starts vport (re)creation, to mark the F_Port as a fabric node (NLP_FABRIC) and allow the F_Port node to fully be created and show up in the node list. - When remote ports are cleaned up on vport termination, cleanup the nameserver and FDMI controller nodes on the vport so they unregister from the transport. - On link bounces, don't exclude the NPIV Fabric remote ports from transitioning to the NPR state, allowing them to avoid re-registration if already registered. Link: https://lore.kernel.org/r/20201115192646.12977-9-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
When a target swap happens, under certain conditions the node sends a LOGO. The unsolicited ELS logic responds with a reject. The logic may allocate a new node to handle this. Afterward, the new nodes are dropped incorrectly leaving them in a mis-matched state and refcounting causes a use-after-free situation leading to a crash. It is also possible that the unsolicited els handling finds a node which is in an UNUSED state. The handling moves these nodes to NPR state with a refcount of 1. Although the end of the discovery logic assumes a final put will free such a node, there are codes paths which could increment the reference count, thus the node is in NPR state and not released. Eventually this mismatch in state and refcount leads to premature release of the node causing a crash. Fix by always using the discovery engine DEVICE RM event to decrement and release the nodes (rather than explicit code that tried to do it before). This will take care of moving the node to the UNUSED state and then removes the final ref count. If there is a trigger to reuse this node, the transition from the UNUSED state clearly indicates that the initial reference is then incremented and use can continue. Link: https://lore.kernel.org/r/20201115192646.12977-8-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
When a PLOGI/ADISC/PRLI/REG_RPI fails, the node remains in the nodelist in that state. Although the driver now frees a node when the ref count goes to zero, in this case the ref cnt doesn't reach zero because there isn't a mechanism to release the final reference. Discovery just stops. Fix by calling the node discovery state machine DEVICE_RM event whenever one of these commands fail. This will remove the final reference count and trigger node release. Link: https://lore.kernel.org/r/20201115192646.12977-7-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
Currently the discovery layers within the driver use the SCSI midlayer host_lock to access node-specific structures. This can contend with the I/O path and is too coarse of a lock. Rework the driver so that it uses a lock specific to the remote port node structure when accessing the structure contents. A few of the changes brought out spots were some slightly reorganized routines worked better. Link: https://lore.kernel.org/r/20201115192646.12977-6-james.smart@broadcom.comCo-developed-by:
-
