- 17 Nov, 2020 19 commits
-
-
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:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
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:
-
James Smart authored
Due to bug history and code review, the node reference counting approach in the driver isn't implemented consistently with how the scsi and nvme transport perform registrations and unregistrations and their callbacks. This resulted in many bad/stale node pointers. Reword the driver so that reference handling is performed as follows: - The initial node reference is taken on structure allocation - Take a reference on any add/register call to the transport - Remove a reference on any delete/unregister call to the transport - After the node has fully removed from both the SCSI and NVMEe transports (dev_loss_callbacks have called back) call the discovery engine DEVICE_RM event which will remove the final reference and release the node structure. - Alter dev_loss handling when a vport or base port is unloading. - Remove the put_node handling - no longer needed. - Rewrite the vport_delete handling on reference counts. Part of this effort was driven from the FDISC not registering with the transport and disrupting the model for node reference counting. - Deleted lpfc_nlp_remove. Pushed it's remaining ops into lpfc_nlp_release. - Several other small code cleanups. Link: https://lore.kernel.org/r/20201115192646.12977-5-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
The lpfc driver is calling get_device and put_device on scsi_fc_transport device structure. When this code was removed, the driver triggered an oops in "scsi_is_host_dev" when the first SCSI target was unregistered from the transport. The reason the calls were necessary is that the driver is calling scsi_remove_host too early, before the target rports are unregistered and the scsi devices disconnected from the scsi_host. The fc_host was torn down during fc_remove_host. Fix by moving the lpfc_pci_remove_one_s3/s4 calls to scsi_remove_host to after the nodes are cleaned up. Remove the get_device and put_device calls and the supporting code. Link: https://lore.kernel.org/r/20201115192646.12977-4-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
Now that the driver has gone to a normal ref interface (with no odd logic) the discovery logic needs to be updated to reworked so that it properly takes references when it should and give them up when it should. Rework the driver for the following get/put model: - Move gets to just before an I/O is issued. Add gets for places where an I/O was issued without one. - Ensure that failures from lpfc_nlp_get() are handled by the driver. - Check and fix the placement of lpfc_nlp_puts relative to io completions. Note: some of these paths may not release the reference on the exact io completion as the reference is held as the code takes another step in the discovery thread and which may cause another io to be issued. - Rearrange some code for error processing and calling lpfc_nlp_put. - Fix some places of incorrect reference freeing that was causing the premature releasing of the structure. - Nvmet plogi handling performs unreg_rpi's. The reference counts were unbalanced resulting in premature node removal. In some cases this caused loss of node discovery. Corrected the reftaking around nvmet plogis. Nodes that experience devloss now get released from the node list now that there is a proper reference taking. Link: https://lore.kernel.org/r/20201115192646.12977-3-james.smart@broadcom.comCo-developed-by:
-
James Smart authored
When a remote port is disconnected and disappears, its node structure (ndlp) stays allocated and on a vport node list. While on the list it can be matched, thus requires validation checks on state to be added in numerous code paths. If the node comes back, its possible for there to be multiple node structures for the same device on the vport node list. There is no reason to keep the node structure around after it is no longer in existence, and the current implementation creates problems for itself (multiple nodes) and lots of unnecessary code for state validation. Additionally, the reference taking on the node structure didn't follow the normal model used by the kernel kref api. It included lots of odd logic to match state with reference count. The combination of this odd logic plus the way it was implicitly used in the discovery engine made its reference taking implementation suspect and extremely hard to follow. Change the driver such that the reference taking routines are now normal ref increments/decrements and callout on refcount=0. With this in place, the rework can be done such that the node structure is fully removed and deallocated when the remote port no longer exists and all references are removed. This removal logic, and the basic ref counting are intrically tied, thus in a single patch. Link: https://lore.kernel.org/r/20201115192646.12977-2-james.smart@broadcom.comCo-developed-by:
-
Zou Wei authored
Fix the following sparse warning: ./be_main.c:167:25: warning: symbol 'beiscsi_attrs' was not declared. Should it be static? Link: https://lore.kernel.org/r/1605339474-22329-1-git-send-email-zou_wei@huawei.comSigned-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
-
Eric Biggers authored
QCOM_SCM is only needed to make the qcom_scm_*() calls in ufs-qcom-ice.c, which is only compiled when SCSI_UFS_CRYPTO=y. So don't unnecessarily enable QCOM_SCM when SCSI_UFS_CRYPTO=n. Link: https://lore.kernel.org/r/20201114004754.235378-1-ebiggers@kernel.orgSigned-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/hpsa.c: In function ‘hpsa_volume_offline’: drivers/scsi/hpsa.c:3885:5: warning: variable ‘scsi_status’ set but not used [-Wunused-but-set-variable] drivers/scsi/hpsa.c:3884:6: warning: variable ‘cmd_status’ set but not used [-Wunused-but-set-variable] drivers/scsi/hpsa.c: In function ‘hpsa_update_scsi_devices’: drivers/scsi/hpsa.c:4354:9: warning: variable ‘n_ext_target_devs’ set but not used [-Wunused-but-set-variable] drivers/scsi/hpsa.c: In function ‘hpsa_scatter_gather’: drivers/scsi/hpsa.c:4583:36: warning: variable ‘last_sg’ set but not used [-Wunused-but-set-variable] drivers/scsi/hpsa.c: In function ‘hpsa_init_one’: drivers/scsi/hpsa.c:8639:6: warning: variable ‘dac’ set but not used [-Wunused-but-set-variable] drivers/scsi/hpsa.c: In function ‘hpsa_enter_performant_mode’: drivers/scsi/hpsa.c:9300:7: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20201112101929.GC1997862@dell Cc: Don Brace <don.brace@microchip.com> Cc: Bugfixes to <esc.storagedev@microsemi.com> Cc: storagedev@microchip.com Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Stanley Chu authored
Once HBA enabling has failed, add retry mechanism and allow vendors to apply specific tweaks before the next retry. For example, vendors can do vendor-specific host reset flow in variant function "ufshcd_vops_hce_enable_notify()". Link: https://lore.kernel.org/r/20201112054537.22494-1-stanley.chu@mediatek.comReviewed-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Don Brace authored
Link: https://lore.kernel.org/r/160512629093.2359.13675060282143622110.stgit@brunhildaReviewed-by:
Scott Benesh <scott.benesh@microchip.com> Reviewed-by:
Scott Teel <scott.teel@microchip.com> Reviewed-by:
Gerry Morong <gerry.morong@microchip.com> Signed-off-by:
Don Brace <don.brace@microchip.com> Signed-off-by:
-
Don Brace authored
Remove unbalanced call to pqi_ctrl_unbusy. Link: https://lore.kernel.org/r/160512628513.2359.17193493825283879603.stgit@brunhildaReviewed-by:
Kevin Barnett <kevin.barnett@microchip.com> Signed-off-by:
-
Don Brace authored
Correct rmmod hangs when using HBA disks with write cache enabled. Do not set controller flag "in_shutdown" during rmmod. SCSI SYNCHRONIZE CACHE(10) and SCSI SYNCHRONIZE CACHE(16) requests were blocked with SCSI_MLQUEUE_HOST_BUSY. Link: https://lore.kernel.org/r/160512627928.2359.10698615071827614781.stgit@brunhildaReviewed-by:
-
Lee Jones authored
Hasn't been used since 2009. Fixes the following W=1 kernel build warning(s): drivers/scsi/pm8001/pm8001_hwi.c: In function ‘mpi_set_phys_g3_with_ssc’: drivers/scsi/pm8001/pm8001_hwi.c:415:6: warning: variable ‘value’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20201116104119.816527-1-lee.jones@linaro.org Cc: Jack Wang <jinpu.wang@cloud.ionos.com> Acked-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
-
Nick Desaulniers authored
Clang is more aggressive about -Wformat warnings when the format flag specifies a type smaller than the parameter. Turns out, struct Scsi_Host's member can_queue is actually an int. Fixes: [-Wformat] shost_rd_attr(can_queue, "%hd\n"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ %d Link: https://github.com/ClangBuiltLinux/linux/issues/378 Link: https://lore.kernel.org/r/20201107081132.2629071-1-ndesaulniers@google.comReviewed-by:Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Martin Wilck authored
This makes the code slightly more readable. Link: https://lore.kernel.org/r/20201029170846.14786-2-mwilck@suse.comReviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Martin Wilck <mwilck@suse.com> Signed-off-by:
-
Martin Wilck authored
The current implementation of scsi_vpd_lun_id() uses the designator length as an implicit measure of priority. This works most of the time, but not always. For example, some Hitachi storage arrays return this in VPD 0x83: VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 24 designator_type: T10 vendor identification, code_set: ASCII associated with the Addressed logical unit vendor id: HITACHI vendor specific: 5030C3502025 Designation descriptor number 2, descriptor length: 6 designator_type: vendor specific [0x0], code_set: Binary associated with the Target port vendor specific: 08 03 Designation descriptor number 3, descriptor length: 20 designator_type: NAA, code_set: Binary associated with the Addressed logical unit NAA 6, IEEE Company_id: 0x60e8 Vendor Specific Identifier: 0x7c35000 Vendor Specific Identifier Extension: 0x30c35000002025 [0x60060e8007c350000030c35000002025] The current code would use the first descriptor because it's longer than the NAA descriptor. But this is wrong, the kernel is supposed to prefer NAA descriptors over T10 vendor ID. Designator length should only be used to compare designators of the same type. This patch addresses the issue by separating designator priority and length. Link: https://lore.kernel.org/r/20201029170846.14786-1-mwilck@suse.com Fixes: 9983bed3 ("scsi: Add scsi_vpd_lun_id()") Reviewed-by:
-
- 11 Nov, 2020 21 commits
-
-
Kaixu Xia authored
Fix the following coccicheck warning: ./drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2089:5-23: WARNING: Comparison to bool ./drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2187:5-23: WARNING: Comparison to bool Link: https://lore.kernel.org/r/1604767920-8361-1-git-send-email-kaixuxia@tencent.comReported-by:
Tosk Robot <tencent_os_robot@tencent.com> Acked-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
Kaixu Xia <kaixuxia@tencent.com> Signed-off-by:
-
Vaibhav Gupta authored
PCI helper functions such as pci_enable/disable_device(), pci_save/restore_state(), pci_set_power_state(), etc. were used by the legacy framework to perform standard operations related to PCI PM. This driver is using the generic framework and thus calls for those functions should be dropped as those tasks are now performed by the PCI core. Link: https://lore.kernel.org/r/20201107100420.149521-1-vaibhavgupta40@gmail.comAcked-by:
Artur Paszkiewicz <artur.paszkiewicz@intel.com> Signed-off-by:
Vaibhav Gupta <vaibhavgupta40@gmail.com> Signed-off-by:
-
Stanley Chu authored
Provide HS-G4 support in MediaTek UFS platforms. To support HS-G4, introduce mechanism to get the MediaTek UFS controller version. With such information, driver can make right decision to apply different configurations in different controllers. Link: https://lore.kernel.org/r/20201029115750.24391-7-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
Some vendors need newer UniPro version to decide if some features can be enabled or not. Simply add missing enums for the latest UniPro versions. Link: https://lore.kernel.org/r/20201029115750.24391-6-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
Support an option to allow users to disable auto-hibern8 feature. Instead, enable hibern8-during-clk-gating feature to keep similar power consumption. Link: https://lore.kernel.org/r/20201029115750.24391-5-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
UFS proprietary features (including features introduced later) in MediaTek UFS platforms have complicated combinations among different platforms. To ease code readability and maintenance, decouple all proprietary features from platform bindings. Each feature would be enabled only if specific property string is defined in device tree node. Link: https://lore.kernel.org/r/20201029115750.24391-4-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
Some MediaTek UFS platforms need to control VA09 power specifically. Provide such control according to the device tree binding. Link: https://lore.kernel.org/r/20201029115750.24391-3-stanley.chu@mediatek.comSigned-off-by:
-
Stanley Chu authored
In ufs_mtk_unipro_set_lpm(), use specific unsigned values as the argument to invoke ufshcd_dme_set(). At the same time, change the name of ufs_mtk_unipro_set_pm() to ufs_mtk_unipro_set_lpm() to align the naming convention in MediaTek UFS driver. Link: https://lore.kernel.org/r/20201029115750.24391-2-stanley.chu@mediatek.comSigned-off-by:
-
Hannes Reinecke authored
Whenever we encounter a sense code of ALUA transitioning in scsi_io_completion() it means that the SCSI midlayer ran out of retries trying to wait for ALUA transitioning. In these cases we should be passing up the error, but signalling that the I/O might be retried, preferably on another path. So return BLK_STS_AGAIN in these cases. [mkp: typo + fallthrough] Link: https://lore.kernel.org/r/20200930080256.90964-5-hare@suse.deReviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Hannes Reinecke authored
We should be setting the 'transitioning' ALUA state once we get a Unit Attention indicating the array is in transitioning. There are arrays which cannot respond to an RTPG while in transitioning, and others have issues correctly reporting the state. So better to set the state during Unit Attention handling and wait for TUR / RTPG to run its course. Link: https://lore.kernel.org/r/20200930080256.90964-4-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
When the ALUA state indicates transitioning we should not retry the command immediately, but rather complete the command with BLK_STS_AGAIN to signal the completion handler that it might be retried. This allows multipathing to redirect the command to another path if possible, and avoid stalls during lengthy transitioning times. Link: https://lore.kernel.org/r/20200930080256.90964-3-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
blk_mq_end_request() will use the block status returned from queue_rq() as argument, except in one instance in blk_mq_dispatch_rq_list(), where the generic BLK_STS_IOERR is used. Link: https://lore.kernel.org/r/20200930080256.90964-2-hare@suse.deReviewed-by:
-
Mike Christie authored
Bodo knows the code better than me now, has time to review patches and is excellent at it, and has lots of ideas for how to make the driver better, so this patch adds him as the maintainer. There was no entry in there already. Andy had posted on the list here: https://www.spinics.net/lists/target-devel/msg14690.html when it got transitioned to me. I added an entry because several companies used it and I thought it would be easy for them to find Bodo. Link: https://lore.kernel.org/r/1604521666-16573-1-git-send-email-michael.christie@oracle.com Cc: Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
-
Lee Jones authored
It's only utilised when debugging is enabled. Fixes the following W=1 kernel build warning(s): drivers/scsi/dc395x.c: In function ‘start_scsi’: drivers/scsi/dc395x.c:1359:6: warning: variable ‘s_stat2’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20201102142359.561122-19-lee.jones@linaro.org Cc: Oliver Neukum <oliver@neukum.org> Cc: Ali Akcaagac <aliakc@web.de> Cc: Jamie Lenehan <lenehan@twibble.org> Cc: "C.L. Huang" <ching@tekram.com.tw> Cc: Erich Chen <erich@tekram.com.tw> Cc: Kurt Garloff <garloff@suse.de> Cc: dc395x@twibble.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/dc395x.c: In function ‘data_io_transfer’: drivers/scsi/dc395x.c:2400:16: warning: variable ‘data2’ set but not used [-Wunused-but-set-variable] drivers/scsi/dc395x.c:2400:6: warning: variable ‘data’ set but not used [-Wunused-but-set-variable] drivers/scsi/dc395x.c: In function ‘reselect’: drivers/scsi/dc395x.c:2992:5: warning: variable ‘arblostflag’ set but not used [-Wunused-but-set-variable] drivers/scsi/dc395x.c: In function ‘doing_srb_done’: drivers/scsi/dc395x.c:3393:28: warning: variable ‘dir’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20201102142359.561122-18-lee.jones@linaro.org Cc: Oliver Neukum <oliver@neukum.org> Cc: Ali Akcaagac <aliakc@web.de> Cc: Jamie Lenehan <lenehan@twibble.org> Cc: "C.L. Huang" <ching@tekram.com.tw> Cc: Erich Chen <erich@tekram.com.tw> Cc: Kurt Garloff <garloff@suse.de> Cc: dc395x@twibble.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/advansys.c: In function ‘asc_prt_asc_board_eeprom’: drivers/scsi/advansys.c:2879:15: warning: variable ‘asc_dvc_varp’ set but not used [-Wunused-but-set-variable] drivers/scsi/advansys.c: In function ‘asc_prt_driver_conf’: drivers/scsi/advansys.c:3174:6: warning: variable ‘chip_scsi_id’ set but not used [-Wunused-but-set-variable] drivers/scsi/advansys.c: In function ‘AdvISR’: drivers/scsi/advansys.c:6114:9: warning: variable ‘target_bit’ set but not used [-Wunused-but-set-variable] Link: https://lore.kernel.org/r/20201102142359.561122-17-lee.jones@linaro.org Cc: Matthew Wilcox <willy@infradead.org> Cc: Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/esas2r/esas2r_main.c:911: warning: Function parameter or member 'a' not described in 'esas2r_check_active_queue' drivers/scsi/esas2r/esas2r_main.c:911: warning: Function parameter or member 'abort_request' not described in 'esas2r_check_active_queue' drivers/scsi/esas2r/esas2r_main.c:911: warning: Function parameter or member 'cmd' not described in 'esas2r_check_active_queue' drivers/scsi/esas2r/esas2r_main.c:911: warning: Function parameter or member 'queue' not described in 'esas2r_check_active_queue' Link: https://lore.kernel.org/r/20201102142359.561122-16-lee.jones@linaro.org Cc: Bradley Grove <linuxdrivers@attotech.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/lpfc/lpfc_nvmet.c:386: warning: Function parameter or member 'ctx_buf' not described in 'lpfc_nvmet_ctxbuf_post' drivers/scsi/lpfc/lpfc_nvmet.c:386: warning: Excess function parameter 'ctxp' description in 'lpfc_nvmet_ctxbuf_post' drivers/scsi/lpfc/lpfc_nvmet.c:386: warning: Excess function parameter 'mp' description in 'lpfc_nvmet_ctxbuf_post' drivers/scsi/lpfc/lpfc_nvmet.c:1310: warning: Function parameter or member 'targetport' not described in 'lpfc_nvmet_ls_req' drivers/scsi/lpfc/lpfc_nvmet.c:1310: warning: Function parameter or member 'hosthandle' not described in 'lpfc_nvmet_ls_req' drivers/scsi/lpfc/lpfc_nvmet.c:1310: warning: Function parameter or member 'pnvme_lsreq' not described in 'lpfc_nvmet_ls_req' drivers/scsi/lpfc/lpfc_nvmet.c:1350: warning: Function parameter or member 'hosthandle' not described in 'lpfc_nvmet_ls_abort' drivers/scsi/lpfc/lpfc_nvmet.c:1350: warning: Function parameter or member 'pnvme_lsreq' not described in 'lpfc_nvmet_ls_abort' drivers/scsi/lpfc/lpfc_nvmet.c:3607: warning: Function parameter or member 'phba' not described in 'lpfc_nvmet_invalidate_host' drivers/scsi/lpfc/lpfc_nvmet.c:3607: warning: Function parameter or member 'ndlp' not described in 'lpfc_nvmet_invalidate_host' Link: https://lore.kernel.org/r/20201102142359.561122-15-lee.jones@linaro.org Cc: James Smart <james.smart@broadcom.com> Cc: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/esas2r/esas2r_int.c: In function ‘esas2r_doorbell_interrupt’: drivers/scsi/esas2r/esas2r_int.c:692:22: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] drivers/scsi/esas2r/esas2r_int.c: In function ‘esas2r_send_reset_ae’: drivers/scsi/esas2r/esas2r_int.c:868:44: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] Link: https://lore.kernel.org/r/20201102142359.561122-14-lee.jones@linaro.org Cc: Bradley Grove <linuxdrivers@attotech.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/lpfc/lpfc_nvme.c: In function ‘lpfc_nvme_ls_abort’: drivers/scsi/lpfc/lpfc_nvme.c:943:19: warning: variable ‘phba’ set but not used [-Wunused-but-set-variable] drivers/scsi/lpfc/lpfc_nvme.c:256: warning: Excess function parameter 'lpfc_pnvme' description in 'lpfc_nvme_create_queue' drivers/scsi/lpfc/lpfc_nvme.c:804: warning: Function parameter or member 'pnvme_rport' not described in 'lpfc_nvme_ls_req' drivers/scsi/lpfc/lpfc_nvme.c:804: warning: Excess function parameter 'nvme_rport' description in 'lpfc_nvme_ls_req' drivers/scsi/lpfc/lpfc_nvme.c:1312: warning: Function parameter or member 'lpfc_ncmd' not described in 'lpfc_nvme_prep_io_cmd' drivers/scsi/lpfc/lpfc_nvme.c:1312: warning: Excess function parameter 'lpfcn_cmd' description in 'lpfc_nvme_prep_io_cmd' drivers/scsi/lpfc/lpfc_nvme.c:1416: warning: Function parameter or member 'lpfc_ncmd' not described in 'lpfc_nvme_prep_io_dma' drivers/scsi/lpfc/lpfc_nvme.c:1416: warning: Excess function parameter 'lpfcn_cmd' description in 'lpfc_nvme_prep_io_dma' drivers/scsi/lpfc/lpfc_nvme.c:1594: warning: bad line: indicated in @lpfc_nvme_rport. drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Function parameter or member 'pnvme_lport' not described in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Function parameter or member 'pnvme_rport' not described in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Function parameter or member 'pnvme_fcreq' not described in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Excess function parameter 'lpfc_pnvme' description in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Excess function parameter 'lpfc_nvme_lport' description in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Excess function parameter 'lpfc_nvme_rport' description in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1605: warning: Excess function parameter 'lpfc_nvme_fcreq' description in 'lpfc_nvme_fcp_io_submit' drivers/scsi/lpfc/lpfc_nvme.c:1852: warning: Function parameter or member 'abts_cmpl' not described in 'lpfc_nvme_abort_fcreq_cmpl' drivers/scsi/lpfc/lpfc_nvme.c:1852: warning: Excess function parameter 'rspiocb' description in 'lpfc_nvme_abort_fcreq_cmpl' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Function parameter or member 'pnvme_lport' not described in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Function parameter or member 'pnvme_rport' not described in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Function parameter or member 'pnvme_fcreq' not described in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Excess function parameter 'lpfc_pnvme' description in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Excess function parameter 'lpfc_nvme_lport' description in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Excess function parameter 'lpfc_nvme_rport' description in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:1888: warning: Excess function parameter 'lpfc_nvme_fcreq' description in 'lpfc_nvme_fcp_abort' drivers/scsi/lpfc/lpfc_nvme.c:2089: warning: Function parameter or member 'ndlp' not described in 'lpfc_get_nvme_buf' drivers/scsi/lpfc/lpfc_nvme.c:2089: warning: Function parameter or member 'idx' not described in 'lpfc_get_nvme_buf' drivers/scsi/lpfc/lpfc_nvme.c:2089: warning: Function parameter or member 'expedite' not described in 'lpfc_get_nvme_buf' drivers/scsi/lpfc/lpfc_nvme.c:2193: warning: Function parameter or member 'vport' not described in 'lpfc_nvme_create_localport' drivers/scsi/lpfc/lpfc_nvme.c:2326: warning: Function parameter or member 'vport' not described in 'lpfc_nvme_destroy_localport' drivers/scsi/lpfc/lpfc_nvme.c:2326: warning: Excess function parameter 'pnvme' description in 'lpfc_nvme_destroy_localport' drivers/scsi/lpfc/lpfc_nvme.c:2544: warning: Function parameter or member 'vport' not described in 'lpfc_nvme_rescan_port' drivers/scsi/lpfc/lpfc_nvme.c:2544: warning: Function parameter or member 'ndlp' not described in 'lpfc_nvme_rescan_port' Link: https://lore.kernel.org/r/20201102142359.561122-13-lee.jones@linaro.org Cc: James Smart <james.smart@broadcom.com> Cc: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/scsi/ufs/ufshcd.c:6603: warning: Function parameter or member 'hba' not described in 'ufshcd_try_to_abort_task' drivers/scsi/ufs/ufshcd.c:6603: warning: Function parameter or member 'tag' not described in 'ufshcd_try_to_abort_task' drivers/scsi/ufs/ufshcd.c:6603: warning: Excess function parameter 'cmd' description in 'ufshcd_try_to_abort_task' Link: https://lore.kernel.org/r/20201102142359.561122-12-lee.jones@linaro.org Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Avri Altman <avri.altman@wdc.com> Cc: Santosh Yaraganavi <santosh.sy@samsung.com> Cc: Vinayak Holikatti <h.vinayak@samsung.com> Signed-off-by:
-
