sfrench/cifs-2.6.git
3 years agoscsi: ufs: ufs-exynos: Use device parameter initialization function
Stanley Chu [Mon, 16 Nov 2020 06:50:50 +0000 (14:50 +0800)]
scsi: ufs: ufs-exynos: Use device parameter initialization function

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.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: ufs-qcom: Use device parameter initialization function
Stanley Chu [Mon, 16 Nov 2020 06:50:49 +0000 (14:50 +0800)]
scsi: ufs: ufs-qcom: Use device parameter initialization function

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.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: ufs-mediatek: Use device parameter initialization function
Stanley Chu [Mon, 16 Nov 2020 06:50:48 +0000 (14:50 +0800)]
scsi: ufs: ufs-mediatek: Use device parameter initialization function

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.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: Introduce device parameter initialization function
Stanley Chu [Mon, 16 Nov 2020 06:50:47 +0000 (14:50 +0800)]
scsi: ufs: Introduce device parameter initialization function

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.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: ufs-mediatek: Refactor performance scaling functions
Stanley Chu [Mon, 16 Nov 2020 06:50:46 +0000 (14:50 +0800)]
scsi: ufs: ufs-mediatek: Refactor performance scaling functions

Refactor performance scaling related functions in MediaTek UFS driver.

Link: https://lore.kernel.org/r/20201116065054.7658-2-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: Update changed file copyrights for 2020
James Smart [Sun, 15 Nov 2020 19:26:46 +0000 (11:26 -0800)]
scsi: lpfc: Update changed file copyrights for 2020

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Update lpfc version to 12.8.0.6
James Smart [Sun, 15 Nov 2020 19:26:45 +0000 (11:26 -0800)]
scsi: lpfc: Update lpfc version to 12.8.0.6

Update lpfc version to 12.8.0.6

Link: https://lore.kernel.org/r/20201115192646.12977-17-james.smart@broadcom.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Convert abort handling to SLI-3 and SLI-4 handlers
James Smart [Sun, 15 Nov 2020 19:26:44 +0000 (11:26 -0800)]
scsi: lpfc: Convert abort handling to SLI-3 and SLI-4 handlers

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Convert SCSI I/O completions to SLI-3 and SLI-4 handlers
James Smart [Sun, 15 Nov 2020 19:26:43 +0000 (11:26 -0800)]
scsi: lpfc: Convert SCSI I/O completions to SLI-3 and SLI-4 handlers

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Convert SCSI path to use common I/O submission path
James Smart [Sun, 15 Nov 2020 19:26:42 +0000 (11:26 -0800)]
scsi: lpfc: Convert SCSI path to use common I/O submission path

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Enable common send_io interface for SCSI and NVMe
James Smart [Sun, 15 Nov 2020 19:26:41 +0000 (11:26 -0800)]
scsi: lpfc: Enable common send_io interface for SCSI and NVMe

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Enable common wqe_template support for both SCSI and NVMe
James Smart [Sun, 15 Nov 2020 19:26:40 +0000 (11:26 -0800)]
scsi: lpfc: Enable common wqe_template support for both SCSI and NVMe

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Refactor WQE structure definitions for common use
James Smart [Sun, 15 Nov 2020 19:26:39 +0000 (11:26 -0800)]
scsi: lpfc: Refactor WQE structure definitions for common use

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Fix NPIV Fabric Node reference counting
James Smart [Sun, 15 Nov 2020 19:26:38 +0000 (11:26 -0800)]
scsi: lpfc: Fix NPIV Fabric Node reference counting

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Fix NPIV discovery and Fabric Node detection
James Smart [Sun, 15 Nov 2020 19:26:37 +0000 (11:26 -0800)]
scsi: lpfc: Fix NPIV discovery and Fabric Node detection

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Unsolicited ELS leaves node in incorrect state while dropping it
James Smart [Sun, 15 Nov 2020 19:26:36 +0000 (11:26 -0800)]
scsi: lpfc: Unsolicited ELS leaves node in incorrect state while dropping it

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Remove ndlp when a PLOGI/ADISC/PRLI/REG_RPI ultimately fails
James Smart [Sun, 15 Nov 2020 19:26:35 +0000 (11:26 -0800)]
scsi: lpfc: Remove ndlp when a PLOGI/ADISC/PRLI/REG_RPI ultimately fails

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Rework remote port lock handling
James Smart [Sun, 15 Nov 2020 19:26:34 +0000 (11:26 -0800)]
scsi: lpfc: Rework remote port lock handling

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Fix refcounting around SCSI and NVMe transport APIs
James Smart [Sun, 15 Nov 2020 19:26:33 +0000 (11:26 -0800)]
scsi: lpfc: Fix refcounting around SCSI and NVMe transport APIs

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Fix removal of SCSI transport device get and put on dev structure
James Smart [Sun, 15 Nov 2020 19:26:32 +0000 (11:26 -0800)]
scsi: lpfc: Fix removal of SCSI transport device get and put on dev structure

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Rework locations of ndlp reference taking
James Smart [Sun, 15 Nov 2020 19:26:31 +0000 (11:26 -0800)]
scsi: lpfc: Rework locations of ndlp reference taking

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: lpfc: Rework remote port ref counting and node freeing
James Smart [Sun, 15 Nov 2020 19:26:30 +0000 (11:26 -0800)]
scsi: lpfc: Rework remote port ref counting and node freeing

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.com
Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-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>
3 years agoscsi: be2iscsi: Mark beiscsi_attrs with static keyword
Zou Wei [Sat, 14 Nov 2020 07:37:54 +0000 (15:37 +0800)]
scsi: be2iscsi: Mark beiscsi_attrs with static keyword

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.com
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs-qcom: Only select QCOM_SCM if SCSI_UFS_CRYPTO
Eric Biggers [Sat, 14 Nov 2020 00:47:54 +0000 (16:47 -0800)]
scsi: ufs-qcom: Only select QCOM_SCM if SCSI_UFS_CRYPTO

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.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: hpsa: Strip out a bunch of set but unused variables
Lee Jones [Thu, 12 Nov 2020 10:19:29 +0000 (10:19 +0000)]
scsi: hpsa: Strip out a bunch of set but unused variables

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: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: Add retry flow for failed HBA enabling
Stanley Chu [Thu, 12 Nov 2020 05:45:37 +0000 (13:45 +0800)]
scsi: ufs: Add retry flow for failed HBA enabling

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.com
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: smartpqi: Update version to 1.2.16-012
Don Brace [Wed, 11 Nov 2020 20:24:50 +0000 (14:24 -0600)]
scsi: smartpqi: Update version to 1.2.16-012

Link: https://lore.kernel.org/r/160512629093.2359.13675060282143622110.stgit@brunhilda
Reviewed-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: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: smartpqi: Correct pqi_sas_smp_handler busy condition
Don Brace [Wed, 11 Nov 2020 20:24:45 +0000 (14:24 -0600)]
scsi: smartpqi: Correct pqi_sas_smp_handler busy condition

Remove unbalanced call to pqi_ctrl_unbusy.

Link: https://lore.kernel.org/r/160512628513.2359.17193493825283879603.stgit@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Kevin Barnett <kevin.barnett@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: smartpqi: Correct driver removal with HBA disks
Don Brace [Wed, 11 Nov 2020 20:24:39 +0000 (14:24 -0600)]
scsi: smartpqi: Correct driver removal with HBA disks

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@brunhilda
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: pm8001: Remove unused variable 'value'
Lee Jones [Mon, 16 Nov 2020 10:41:19 +0000 (10:41 +0000)]
scsi: pm8001: Remove unused variable 'value'

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: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: core: Fix -Wformat for scsi_host
Nick Desaulniers [Sat, 7 Nov 2020 08:11:32 +0000 (00:11 -0800)]
scsi: core: Fix -Wformat for scsi_host

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.com
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
warning: format specifies type 'short' but the argument has type 'int'

3 years agoscsi: core: Replace while-loop by for-loop in scsi_vpd_lun_id()
Martin Wilck [Thu, 29 Oct 2020 17:08:46 +0000 (18:08 +0100)]
scsi: core: Replace while-loop by for-loop in scsi_vpd_lun_id()

This makes the code slightly more readable.

Link: https://lore.kernel.org/r/20201029170846.14786-2-mwilck@suse.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: core: Fix VPD LUN ID designator priorities
Martin Wilck [Thu, 29 Oct 2020 17:08:45 +0000 (18:08 +0100)]
scsi: core: Fix VPD LUN ID designator priorities

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: 9983bed3907c ("scsi: Add scsi_vpd_lun_id()")
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: bnx2fc: Fix comparison to bool warning
Kaixu Xia [Sat, 7 Nov 2020 16:52:00 +0000 (00:52 +0800)]
scsi: bnx2fc: Fix comparison to bool warning

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.com
Reported-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: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: isci: Don't use PCI helper functions
Vaibhav Gupta [Sat, 7 Nov 2020 10:04:19 +0000 (15:34 +0530)]
scsi: isci: Don't use PCI helper functions

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.com
Acked-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs-mediatek: Add HS-G4 support
Stanley Chu [Thu, 29 Oct 2020 11:57:50 +0000 (19:57 +0800)]
scsi: ufs-mediatek: Add HS-G4 support

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.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: Add enums for UniPro version higher than 1.6
Stanley Chu [Thu, 29 Oct 2020 11:57:49 +0000 (19:57 +0800)]
scsi: ufs: Add enums for UniPro version higher than 1.6

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.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs-mediatek: Support option to disable auto-hibern8
Stanley Chu [Thu, 29 Oct 2020 11:57:48 +0000 (19:57 +0800)]
scsi: ufs-mediatek: Support option to disable auto-hibern8

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.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs-mediatek: Decouple features from platform bindings
Stanley Chu [Thu, 29 Oct 2020 11:57:47 +0000 (19:57 +0800)]
scsi: ufs-mediatek: Decouple features from platform bindings

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.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs-mediatek: Support VA09 regulator operations
Stanley Chu [Thu, 29 Oct 2020 11:57:46 +0000 (19:57 +0800)]
scsi: ufs-mediatek: Support VA09 regulator operations

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.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs-mediatek: Assign arguments with correct type
Stanley Chu [Thu, 29 Oct 2020 11:57:45 +0000 (19:57 +0800)]
scsi: ufs-mediatek: Assign arguments with correct type

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.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: core: Return BLK_STS_AGAIN for ALUA transitioning
Hannes Reinecke [Wed, 30 Sep 2020 08:02:56 +0000 (10:02 +0200)]
scsi: core: Return BLK_STS_AGAIN for ALUA transitioning

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.de
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: scsi_dh_alua: Set 'transitioning' state on Unit Attention
Hannes Reinecke [Wed, 30 Sep 2020 08:02:55 +0000 (10:02 +0200)]
scsi: scsi_dh_alua: Set 'transitioning' state on Unit Attention

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.de
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: scsi_dh_alua: Return BLK_STS_AGAIN for ALUA transitioning state
Hannes Reinecke [Wed, 30 Sep 2020 08:02:54 +0000 (10:02 +0200)]
scsi: scsi_dh_alua: Return BLK_STS_AGAIN for ALUA transitioning state

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.de
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: block: Return status code in blk_mq_end_request()
Hannes Reinecke [Wed, 30 Sep 2020 08:02:53 +0000 (10:02 +0200)]
scsi: block: Return status code in blk_mq_end_request()

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.de
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: MAINTAINERS: Make Bodo target_core_user maintainer
Mike Christie [Wed, 4 Nov 2020 20:27:46 +0000 (14:27 -0600)]
scsi: MAINTAINERS: Make Bodo target_core_user maintainer

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: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: dc395x: Mark 's_stat2' as __maybe_unused
Lee Jones [Mon, 2 Nov 2020 14:23:58 +0000 (14:23 +0000)]
scsi: dc395x: Mark 's_stat2' as __maybe_unused

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: dc395x: Remove a few unused variables
Lee Jones [Mon, 2 Nov 2020 14:23:57 +0000 (14:23 +0000)]
scsi: dc395x: Remove a few unused variables

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: advansys: Relocate or remove unused variables
Lee Jones [Mon, 2 Nov 2020 14:23:56 +0000 (14:23 +0000)]
scsi: advansys: Relocate or remove unused variables

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: esas2r: esas2r_main: Demote non-conformant kernel-doc header
Lee Jones [Mon, 2 Nov 2020 14:23:55 +0000 (14:23 +0000)]
scsi: esas2r: esas2r_main: Demote non-conformant kernel-doc header

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_nvmet: Fix-up some formatting and doc-rot issues
Lee Jones [Mon, 2 Nov 2020 14:23:54 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_nvmet: Fix-up some formatting and doc-rot issues

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: esas2r: esas2r_int: Add brackets around potentially empty if()s
Lee Jones [Mon, 2 Nov 2020 14:23:53 +0000 (14:23 +0000)]
scsi: esas2r: esas2r_int: Add brackets around potentially empty if()s

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_nvme: Fix some kernel-doc related issues
Lee Jones [Mon, 2 Nov 2020 14:23:52 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_nvme: Fix some kernel-doc related issues

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 <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: ufshcd: Fix some function doc-rot
Lee Jones [Mon, 2 Nov 2020 14:23:51 +0000 (14:23 +0000)]
scsi: ufs: ufshcd: Fix some function doc-rot

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: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_nvme: Remove unused variable 'phba'
Lee Jones [Mon, 2 Nov 2020 14:23:50 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_nvme: Remove unused variable 'phba'

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]

Link: https://lore.kernel.org/r/20201102142359.561122-11-lee.jones@linaro.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: esas2r: esas2r_init: Place brackets around a potentially empty if()
Lee Jones [Mon, 2 Nov 2020 14:23:49 +0000 (14:23 +0000)]
scsi: esas2r: esas2r_init: Place brackets around a potentially empty if()

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/esas2r/esas2r_init.c: In function â€˜esas2r_init_adapter’:
 drivers/scsi/esas2r/esas2r_init.c:418:41: warning: suggest braces around empty body in an â€˜else’ statement [-Wempty-body]

Link: https://lore.kernel.org/r/20201102142359.561122-10-lee.jones@linaro.org
Cc: Bradley Grove <linuxdrivers@attotech.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: esas2r: esas2r_disc: Place brackets around a potentially empty if()
Lee Jones [Mon, 2 Nov 2020 14:23:48 +0000 (14:23 +0000)]
scsi: esas2r: esas2r_disc: Place brackets around a potentially empty if()

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/esas2r/esas2r_disc.c: In function â€˜esas2r_disc_get_phys_addr’:
 drivers/scsi/esas2r/esas2r_disc.c:1035:17: warning: suggest braces around empty body in an â€˜if’ statement [-Wempty-body]

Link: https://lore.kernel.org/r/20201102142359.561122-9-lee.jones@linaro.org
Cc: Bradley Grove <linuxdrivers@attotech.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_bsg: Provide correct documentation for a bunch of functions
Lee Jones [Mon, 2 Nov 2020 14:23:47 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_bsg: Provide correct documentation for a bunch of functions

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_bsg.c:917: warning: Function parameter or member 'phba' not described in 'lpfc_bsg_ct_unsol_event'
 drivers/scsi/lpfc/lpfc_bsg.c:917: warning: Function parameter or member 'pring' not described in 'lpfc_bsg_ct_unsol_event'
 drivers/scsi/lpfc/lpfc_bsg.c:1484: warning: Function parameter or member 'cmp' not described in 'lpfc_issue_ct_rsp'
 drivers/scsi/lpfc/lpfc_bsg.c:3900: warning: Function parameter or member 'job' not described in 'lpfc_bsg_sli_cfg_read_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:3900: warning: Function parameter or member 'dmabuf' not described in 'lpfc_bsg_sli_cfg_read_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:3900: warning: Excess function parameter 'mb' description in 'lpfc_bsg_sli_cfg_read_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:3900: warning: Excess function parameter 'dmabuff' description in 'lpfc_bsg_sli_cfg_read_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4088: warning: Function parameter or member 'job' not described in 'lpfc_bsg_sli_cfg_write_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4088: warning: Function parameter or member 'nemb_tp' not described in 'lpfc_bsg_sli_cfg_write_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4088: warning: Function parameter or member 'dmabuf' not described in 'lpfc_bsg_sli_cfg_write_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4088: warning: Excess function parameter 'mb' description in 'lpfc_bsg_sli_cfg_write_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4088: warning: Excess function parameter 'dmabuff' description in 'lpfc_bsg_sli_cfg_write_cmd_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4254: warning: Function parameter or member 'job' not described in 'lpfc_bsg_handle_sli_cfg_mbox'
 drivers/scsi/lpfc/lpfc_bsg.c:4254: warning: Function parameter or member 'dmabuf' not described in 'lpfc_bsg_handle_sli_cfg_mbox'
 drivers/scsi/lpfc/lpfc_bsg.c:4254: warning: Excess function parameter 'mb' description in 'lpfc_bsg_handle_sli_cfg_mbox'
 drivers/scsi/lpfc/lpfc_bsg.c:4254: warning: Excess function parameter 'dmabuff' description in 'lpfc_bsg_handle_sli_cfg_mbox'
 drivers/scsi/lpfc/lpfc_bsg.c:4403: warning: Function parameter or member 'job' not described in 'lpfc_bsg_read_ebuf_get'
 drivers/scsi/lpfc/lpfc_bsg.c:4403: warning: Excess function parameter 'dmabuf' description in 'lpfc_bsg_read_ebuf_get'
 drivers/scsi/lpfc/lpfc_bsg.c:4474: warning: Function parameter or member 'job' not described in 'lpfc_bsg_write_ebuf_set'
 drivers/scsi/lpfc/lpfc_bsg.c:4600: warning: Function parameter or member 'job' not described in 'lpfc_bsg_handle_sli_cfg_ebuf'
 drivers/scsi/lpfc/lpfc_bsg.c:4600: warning: Function parameter or member 'dmabuf' not described in 'lpfc_bsg_handle_sli_cfg_ebuf'
 drivers/scsi/lpfc/lpfc_bsg.c:4600: warning: Excess function parameter 'mb' description in 'lpfc_bsg_handle_sli_cfg_ebuf'
 drivers/scsi/lpfc/lpfc_bsg.c:4600: warning: Excess function parameter 'dmabuff' description in 'lpfc_bsg_handle_sli_cfg_ebuf'
 drivers/scsi/lpfc/lpfc_bsg.c:4645: warning: Function parameter or member 'job' not described in 'lpfc_bsg_handle_sli_cfg_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4645: warning: Function parameter or member 'dmabuf' not described in 'lpfc_bsg_handle_sli_cfg_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4645: warning: Excess function parameter 'mb' description in 'lpfc_bsg_handle_sli_cfg_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4645: warning: Excess function parameter 'dmabuff' description in 'lpfc_bsg_handle_sli_cfg_ext'
 drivers/scsi/lpfc/lpfc_bsg.c:4723: warning: Function parameter or member 'job' not described in 'lpfc_bsg_issue_mbox'
 drivers/scsi/lpfc/lpfc_bsg.c:4723: warning: Excess function parameter 'mb' description in 'lpfc_bsg_issue_mbox'

Link: https://lore.kernel.org/r/20201102142359.561122-8-lee.jones@linaro.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_debugfs: Fix a couple of function documentation issues
Lee Jones [Mon, 2 Nov 2020 14:23:46 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_debugfs: Fix a couple of function documentation issues

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_debugfs.c:4204: warning: Function parameter or member 'len' not described in 'lpfc_idiag_queacc_read_qe'
 drivers/scsi/lpfc/lpfc_debugfs.c:4781: warning: Function parameter or member 'ctlregid' not described in 'lpfc_idiag_ctlacc_read_reg'
 drivers/scsi/lpfc/lpfc_debugfs.c:4781: warning: Excess function parameter 'drbregid' description in 'lpfc_idiag_ctlacc_read_reg'

Link: https://lore.kernel.org/r/20201102142359.561122-7-lee.jones@linaro.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_attr: Fix-up a bunch of kernel-doc misdemeanours
Lee Jones [Mon, 2 Nov 2020 14:23:45 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_attr: Fix-up a bunch of kernel-doc misdemeanours

Fixes the following W=1 kernel build warning(s):

 from drivers/scsi/lpfc/lpfc_attr.c:26:
 inlined from â€˜lpfc_stat_data_ctrl_store’ at drivers/scsi/lpfc/lpfc_attr.c:4165:3:
 drivers/scsi/lpfc/lpfc_attr.c:2537: warning: Function parameter or member 'attr' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2537: warning: Function parameter or member 'default' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2537: warning: Function parameter or member 'minval' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2537: warning: Function parameter or member 'maxval' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2537: warning: Excess function parameter 'phba' description in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2537: warning: Excess function parameter 'val' description in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2792: warning: Function parameter or member 'dev' not described in 'lpfc_soft_wwpn_store'
 drivers/scsi/lpfc/lpfc_attr.c:2886: warning: Function parameter or member 'dev' not described in 'lpfc_soft_wwnn_store'
 drivers/scsi/lpfc/lpfc_attr.c:2886: warning: Function parameter or member 'attr' not described in 'lpfc_soft_wwnn_store'
 drivers/scsi/lpfc/lpfc_attr.c:2886: warning: Excess function parameter 'cdev' description in 'lpfc_soft_wwnn_store'
 drivers/scsi/lpfc/lpfc_attr.c:3224: warning: Function parameter or member 'vpt_wwpn' not described in 'lpfc_oas_lun_state_set'
 drivers/scsi/lpfc/lpfc_attr.c:3224: warning: Function parameter or member 'tgt_wwpn' not described in 'lpfc_oas_lun_state_set'
 drivers/scsi/lpfc/lpfc_attr.c:3224: warning: Function parameter or member 'pri' not described in 'lpfc_oas_lun_state_set'
 drivers/scsi/lpfc/lpfc_attr.c:3224: warning: Excess function parameter 'ndlp' description in 'lpfc_oas_lun_state_set'
 drivers/scsi/lpfc/lpfc_attr.c:3264: warning: Function parameter or member 'lun_pri' not described in 'lpfc_oas_lun_get_next'
 drivers/scsi/lpfc/lpfc_attr.c:3302: warning: Function parameter or member 'pri' not described in 'lpfc_oas_lun_state_change'
 drivers/scsi/lpfc/lpfc_attr.c:3376: warning: Function parameter or member 'count' not described in 'lpfc_oas_lun_store'
 drivers/scsi/lpfc/lpfc_attr.c:3835: warning: Function parameter or member 'vport' not described in 'lpfc_tgt_queue_depth_set'
 drivers/scsi/lpfc/lpfc_attr.c:3835: warning: Excess function parameter 'phba' description in 'lpfc_tgt_queue_depth_set'
 drivers/scsi/lpfc/lpfc_attr.c:4026: warning: Function parameter or member 'dev' not described in 'lpfc_topology_store'
 drivers/scsi/lpfc/lpfc_attr.c:4026: warning: Function parameter or member 'attr' not described in 'lpfc_topology_store'
 drivers/scsi/lpfc/lpfc_attr.c:4026: warning: Function parameter or member 'buf' not described in 'lpfc_topology_store'
 drivers/scsi/lpfc/lpfc_attr.c:4026: warning: Function parameter or member 'count' not described in 'lpfc_topology_store'
 drivers/scsi/lpfc/lpfc_attr.c:4026: warning: Excess function parameter 'phba' description in 'lpfc_topology_store'
 drivers/scsi/lpfc/lpfc_attr.c:4026: warning: Excess function parameter 'val' description in 'lpfc_topology_store'
 drivers/scsi/lpfc/lpfc_attr.c:4148: warning: Function parameter or member 'attr' not described in 'lpfc_stat_data_ctrl_store'
 drivers/scsi/lpfc/lpfc_attr.c:4302: warning: Function parameter or member 'attr' not described in 'lpfc_stat_data_ctrl_show'
 drivers/scsi/lpfc/lpfc_attr.c:4383: warning: Function parameter or member 'buf' not described in 'sysfs_drvr_stat_data_read'
 drivers/scsi/lpfc/lpfc_attr.c:4383: warning: Excess function parameter 'buff' description in 'sysfs_drvr_stat_data_read'
 drivers/scsi/lpfc/lpfc_attr.c:4476: warning: Function parameter or member 'dev' not described in 'lpfc_link_speed_store'
 drivers/scsi/lpfc/lpfc_attr.c:4476: warning: Function parameter or member 'attr' not described in 'lpfc_link_speed_store'
 drivers/scsi/lpfc/lpfc_attr.c:4476: warning: Function parameter or member 'buf' not described in 'lpfc_link_speed_store'
 drivers/scsi/lpfc/lpfc_attr.c:4476: warning: Function parameter or member 'count' not described in 'lpfc_link_speed_store'
 drivers/scsi/lpfc/lpfc_attr.c:4476: warning: Excess function parameter 'phba' description in 'lpfc_link_speed_store'
 drivers/scsi/lpfc/lpfc_attr.c:4476: warning: Excess function parameter 'val' description in 'lpfc_link_speed_store'
 drivers/scsi/lpfc/lpfc_attr.c:7117: warning: Function parameter or member 'verbose' not described in 'lpfc_hba_log_verbose_init'

Link: https://lore.kernel.org/r/20201102142359.561122-6-lee.jones@linaro.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_attr: Demote kernel-doc format for redefined functions
Lee Jones [Mon, 2 Nov 2020 14:23:44 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_attr: Demote kernel-doc format for redefined functions

Kernel-doc does not understand this use-case.

Fixes the following W=1 kernel build warning(s):

 from drivers/scsi/lpfc/lpfc_attr.c:26:
 inlined from â€˜lpfc_stat_data_ctrl_store’ at drivers/scsi/lpfc/lpfc_attr.c:4164:3:
 drivers/scsi/lpfc/lpfc_attr.c:2315: warning: Excess function parameter 'dev' description in 'lpfc_param_show'
 drivers/scsi/lpfc/lpfc_attr.c:2315: warning: Excess function parameter 'buf' description in 'lpfc_param_show'
 drivers/scsi/lpfc/lpfc_attr.c:2343: warning: Excess function parameter 'dev' description in 'lpfc_param_hex_show'
 drivers/scsi/lpfc/lpfc_attr.c:2343: warning: Excess function parameter 'buf' description in 'lpfc_param_hex_show'
 drivers/scsi/lpfc/lpfc_attr.c:2377: warning: Function parameter or member 'attr' not described in 'lpfc_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2377: warning: Function parameter or member 'default' not described in 'lpfc_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2377: warning: Function parameter or member 'minval' not described in 'lpfc_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2377: warning: Function parameter or member 'maxval' not described in 'lpfc_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2377: warning: Excess function parameter 'phba' description in 'lpfc_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2377: warning: Excess function parameter 'val' description in 'lpfc_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2414: warning: Function parameter or member 'attr' not described in 'lpfc_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2414: warning: Function parameter or member 'default' not described in 'lpfc_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2414: warning: Function parameter or member 'minval' not described in 'lpfc_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2414: warning: Function parameter or member 'maxval' not described in 'lpfc_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2414: warning: Excess function parameter 'phba' description in 'lpfc_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2414: warning: Excess function parameter 'val' description in 'lpfc_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2454: warning: Excess function parameter 'dev' description in 'lpfc_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:2454: warning: Excess function parameter 'buf' description in 'lpfc_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:2454: warning: Excess function parameter 'count' description in 'lpfc_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:2478: warning: Excess function parameter 'dev' description in 'lpfc_vport_param_show'
 drivers/scsi/lpfc/lpfc_attr.c:2478: warning: Excess function parameter 'buf' description in 'lpfc_vport_param_show'
 drivers/scsi/lpfc/lpfc_attr.c:2503: warning: Excess function parameter 'dev' description in 'lpfc_vport_param_hex_show'
 drivers/scsi/lpfc/lpfc_attr.c:2503: warning: Excess function parameter 'buf' description in 'lpfc_vport_param_hex_show'
 drivers/scsi/lpfc/lpfc_attr.c:2536: warning: Function parameter or member 'attr' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2536: warning: Function parameter or member 'default' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2536: warning: Function parameter or member 'minval' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2536: warning: Function parameter or member 'maxval' not described in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2536: warning: Excess function parameter 'phba' description in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2536: warning: Excess function parameter 'val' description in 'lpfc_vport_param_init'
 drivers/scsi/lpfc/lpfc_attr.c:2572: warning: Function parameter or member 'attr' not described in 'lpfc_vport_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2572: warning: Function parameter or member 'default' not described in 'lpfc_vport_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2572: warning: Function parameter or member 'minval' not described in 'lpfc_vport_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2572: warning: Function parameter or member 'maxval' not described in 'lpfc_vport_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2572: warning: Excess function parameter 'phba' description in 'lpfc_vport_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2572: warning: Excess function parameter 'val' description in 'lpfc_vport_param_set'
 drivers/scsi/lpfc/lpfc_attr.c:2607: warning: Function parameter or member 'attr' not described in 'lpfc_vport_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:2607: warning: Excess function parameter 'cdev' description in 'lpfc_vport_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:2607: warning: Excess function parameter 'buf' description in 'lpfc_vport_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:2607: warning: Excess function parameter 'count' description in 'lpfc_vport_param_store'
 drivers/scsi/lpfc/lpfc_attr.c:7081: warning: Function parameter or member 'field' not described in 'lpfc_rport_show_function'
 drivers/scsi/lpfc/lpfc_attr.c:7081: warning: Function parameter or member 'format_string' not described in 'lpfc_rport_show_function'
 drivers/scsi/lpfc/lpfc_attr.c:7081: warning: Function parameter or member 'sz' not described in 'lpfc_rport_show_function'
 drivers/scsi/lpfc/lpfc_attr.c:7081: warning: Function parameter or member 'cast' not described in 'lpfc_rport_show_function'
 drivers/scsi/lpfc/lpfc_attr.c:7081: warning: Excess function parameter 'cdev' description in 'lpfc_rport_show_function'
 drivers/scsi/lpfc/lpfc_attr.c:7081: warning: Excess function parameter 'buf' description in 'lpfc_rport_show_function'

Link: https://lore.kernel.org/r/20201102142359.561122-5-lee.jones@linaro.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: lpfc: lpfc_scsi: Fix a whole host of kernel-doc issues
Lee Jones [Mon, 2 Nov 2020 14:23:43 +0000 (14:23 +0000)]
scsi: lpfc: lpfc_scsi: Fix a whole host of kernel-doc issues

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_scsi.c:331: warning: Function parameter or member 'num_to_alloc' not described in 'lpfc_new_scsi_buf_s3'
 drivers/scsi/lpfc/lpfc_scsi.c:331: warning: Excess function parameter 'num_to_allocate' description in 'lpfc_new_scsi_buf_s3'
 drivers/scsi/lpfc/lpfc_scsi.c:507: warning: Function parameter or member 'idx' not described in 'lpfc_sli4_io_xri_aborted'
 drivers/scsi/lpfc/lpfc_scsi.c:593: warning: Function parameter or member 'ndlp' not described in 'lpfc_get_scsi_buf_s3'
 drivers/scsi/lpfc/lpfc_scsi.c:593: warning: Function parameter or member 'cmnd' not described in 'lpfc_get_scsi_buf_s3'
 drivers/scsi/lpfc/lpfc_scsi.c:632: warning: Function parameter or member 'ndlp' not described in 'lpfc_get_scsi_buf_s4'
 drivers/scsi/lpfc/lpfc_scsi.c:632: warning: Function parameter or member 'cmnd' not described in 'lpfc_get_scsi_buf_s4'
 drivers/scsi/lpfc/lpfc_scsi.c:744: warning: Function parameter or member 'ndlp' not described in 'lpfc_get_scsi_buf'
 drivers/scsi/lpfc/lpfc_scsi.c:744: warning: Function parameter or member 'cmnd' not described in 'lpfc_get_scsi_buf'
 drivers/scsi/lpfc/lpfc_scsi.c:986: warning: Function parameter or member 'new_guard' not described in 'lpfc_bg_err_inject'
 drivers/scsi/lpfc/lpfc_scsi.c:1393: warning: Function parameter or member 'txop' not described in 'lpfc_sc_to_bg_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1393: warning: Function parameter or member 'rxop' not described in 'lpfc_sc_to_bg_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1393: warning: Excess function parameter 'txopt' description in 'lpfc_sc_to_bg_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1393: warning: Excess function parameter 'rxopt' description in 'lpfc_sc_to_bg_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1473: warning: Function parameter or member 'txop' not described in 'lpfc_bg_err_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1473: warning: Function parameter or member 'rxop' not described in 'lpfc_bg_err_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1473: warning: Excess function parameter 'txopt' description in 'lpfc_bg_err_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1473: warning: Excess function parameter 'rxopt' description in 'lpfc_bg_err_opcodes'
 drivers/scsi/lpfc/lpfc_scsi.c:1565: warning: Function parameter or member 'datasegcnt' not described in 'lpfc_bg_setup_bpl'
 drivers/scsi/lpfc/lpfc_scsi.c:1565: warning: Excess function parameter 'datacnt' description in 'lpfc_bg_setup_bpl'
 drivers/scsi/lpfc/lpfc_scsi.c:1951: warning: Function parameter or member 'datasegcnt' not described in 'lpfc_bg_setup_sgl'
 drivers/scsi/lpfc/lpfc_scsi.c:1951: warning: Function parameter or member 'lpfc_cmd' not described in 'lpfc_bg_setup_sgl'
 drivers/scsi/lpfc/lpfc_scsi.c:1951: warning: Excess function parameter 'datacnt' description in 'lpfc_bg_setup_sgl'
 drivers/scsi/lpfc/lpfc_scsi.c:2131: warning: Function parameter or member 'lpfc_cmd' not described in 'lpfc_bg_setup_sgl_prot'
 drivers/scsi/lpfc/lpfc_scsi.c:4476: warning: Function parameter or member 't' not described in 'lpfc_poll_timeout'
 drivers/scsi/lpfc/lpfc_scsi.c:4476: warning: Excess function parameter 'ptr' description in 'lpfc_poll_timeout'
 drivers/scsi/lpfc/lpfc_scsi.c:4503: warning: Function parameter or member 'shost' not described in 'lpfc_queuecommand'
 drivers/scsi/lpfc/lpfc_scsi.c:4503: warning: Excess function parameter 'done' description in 'lpfc_queuecommand'
 drivers/scsi/lpfc/lpfc_scsi.c:5035: warning: Function parameter or member 'cmnd' not described in 'lpfc_send_taskmgmt'
 drivers/scsi/lpfc/lpfc_scsi.c:5035: warning: Excess function parameter 'rdata' description in 'lpfc_send_taskmgmt'
 drivers/scsi/lpfc/lpfc_scsi.c:5688: warning: Function parameter or member 'phba' not described in 'lpfc_create_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5688: warning: Function parameter or member 'pri' not described in 'lpfc_create_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5688: warning: Excess function parameter 'pha' description in 'lpfc_create_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5730: warning: Function parameter or member 'phba' not described in 'lpfc_delete_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5730: warning: Excess function parameter 'pha' description in 'lpfc_delete_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5762: warning: Function parameter or member 'phba' not described in '__lpfc_get_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5762: warning: Excess function parameter 'pha' description in '__lpfc_get_device_data'
 drivers/scsi/lpfc/lpfc_scsi.c:5818: warning: Function parameter or member 'phba' not described in 'lpfc_find_next_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5818: warning: Function parameter or member 'found_lun_pri' not described in 'lpfc_find_next_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5818: warning: Excess function parameter 'pha' description in 'lpfc_find_next_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5909: warning: Function parameter or member 'phba' not described in 'lpfc_enable_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5909: warning: Function parameter or member 'pri' not described in 'lpfc_enable_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5909: warning: Excess function parameter 'pha' description in 'lpfc_enable_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5968: warning: Function parameter or member 'phba' not described in 'lpfc_disable_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5968: warning: Function parameter or member 'pri' not described in 'lpfc_disable_oas_lun'
 drivers/scsi/lpfc/lpfc_scsi.c:5968: warning: Excess function parameter 'pha' description in 'lpfc_disable_oas_lun'

Link: https://lore.kernel.org/r/20201102142359.561122-4-lee.jones@linaro.org
Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: mpt3sas_scsih: Fix function documentation formatting
Lee Jones [Mon, 2 Nov 2020 14:23:42 +0000 (14:23 +0000)]
scsi: mpt3sas: mpt3sas_scsih: Fix function documentation formatting

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/mpt3sas/mpt3sas_scsih.c:2778: warning: Function parameter or member 'ioc' not described in 'scsih_tm_cmd_map_status'
 drivers/scsi/mpt3sas/mpt3sas_scsih.c:2778: warning: Function parameter or member 'channel' not described in 'scsih_tm_cmd_map_status'
 drivers/scsi/mpt3sas/mpt3sas_scsih.c:2829: warning: Function parameter or member 'ioc' not described in 'scsih_tm_post_processing'
 drivers/scsi/mpt3sas/mpt3sas_scsih.c:2829: warning: Function parameter or member 'channel' not described in 'scsih_tm_post_processing'

Link: https://lore.kernel.org/r/20201102142359.561122-3-lee.jones@linaro.org
Cc: Sathya Prakash <sathya.prakash@broadcom.com>
Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
Cc: MPT-FusionLinux.pdl@avagotech.com
Cc: MPT-FusionLinux.pdl@broadcom.com
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: aic7xxx: aic79xx_osm: Remove unused variable 'saved_scsiid'
Lee Jones [Mon, 2 Nov 2020 14:23:41 +0000 (14:23 +0000)]
scsi: aic7xxx: aic79xx_osm: Remove unused variable 'saved_scsiid'

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aic7xxx/aic79xx_osm.c: In function â€˜ahd_linux_queue_abort_cmd’:
 drivers/scsi/aic7xxx/aic79xx_osm.c:2143:9: warning: variable â€˜saved_scsiid’ set but not used [-Wunused-but-set-variable]

Link: https://lore.kernel.org/r/20201102142359.561122-2-lee.jones@linaro.org
Cc: Hannes Reinecke <hare@suse.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: pm8001: pm8001_sas: Fix strncpy() warning when space is not left for NUL
Lee Jones [Mon, 2 Nov 2020 10:25:43 +0000 (10:25 +0000)]
scsi: pm8001: pm8001_sas: Fix strncpy() warning when space is not left for NUL

This string is not NUL terminated.

Fixes the following W=1 kernel build warning(s):

 from drivers/scsi/pm8001/pm8001_sas.c:41:
 In function â€˜strncpy’,
 inlined from â€˜pm8001_issue_ssp_tmf’ at drivers/scsi/pm8001/pm8001_sas.c:919:2:
 include/linux/string.h:297:30: warning: â€˜__builtin_strncpy’ specified bound 8 equals destination size [-Wstringop-truncation]
 297 | #define __underlying_strncpy __builtin_strncpy
 | ^
 include/linux/string.h:307:9: note: in expansion of macro â€˜__underlying_strncpy’
 307 | return __underlying_strncpy(p, q, size);
 | ^~~~~~~~~~~~~~~~~~~~

Link: https://lore.kernel.org/r/20201102102544.1018706-2-lee.jones@linaro.org
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: arcmsr: Stop __builtin_strncpy complaining about a lack of space for NUL
Lee Jones [Mon, 2 Nov 2020 10:25:42 +0000 (10:25 +0000)]
scsi: arcmsr: Stop __builtin_strncpy complaining about a lack of space for NUL

SCSI strings like inqdata are not NUL terminated.

Fixes the following W=1 kernel build warning(s):

 In file included from include/linux/bitmap.h:9,
 from include/linux/nodemask.h:95,
 from include/linux/mmzone.h:17,
 from include/linux/gfp.h:6,
 from include/linux/umh.h:4,
 from include/linux/kmod.h:9,
 from include/linux/module.h:16,
 from drivers/scsi/arcmsr/arcmsr_hba.c:47:
 In function â€˜strncpy’,
 inlined from â€˜arcmsr_handle_virtual_command’ at drivers/scsi/arcmsr/arcmsr_hba.c:3055:3:
 include/linux/string.h:297:30: warning: â€˜__builtin_strncpy’ output truncated before terminating nul copying 4 bytes from a string of the same length [-Wstringop-truncation]
 297 | #define __underlying_strncpy __builtin_strncpy
 | ^
 include/linux/string.h:307:9: note: in expansion of macro â€˜__underlying_strncpy’
 307 | return __underlying_strncpy(p, q, size);
 | ^~~~~~~~~~~~~~~~~~~~
 In function â€˜strncpy’,
 inlined from â€˜arcmsr_handle_virtual_command’ at drivers/scsi/arcmsr/arcmsr_hba.c:3053:3:
 include/linux/string.h:297:30: warning: â€˜__builtin_strncpy’ output truncated before terminating nul copying 16 bytes from a string of the same length [-Wstringop-truncation]
 297 | #define __underlying_strncpy __builtin_strncpy
 | ^
 include/linux/string.h:307:9: note: in expansion of macro â€˜__underlying_strncpy’
 307 | return __underlying_strncpy(p, q, size);
 | ^~~~~~~~~~~~~~~~~~~~
 In function â€˜strncpy’,
 inlined from â€˜arcmsr_handle_virtual_command’ at drivers/scsi/arcmsr/arcmsr_hba.c:3051:3:
 include/linux/string.h:297:30: warning: â€˜__builtin_strncpy’ output truncated before terminating nul copying 8 bytes from a string of the same length [-Wstringop-truncation]
 297 | #define __underlying_strncpy __builtin_strncpy
 | ^
 include/linux/string.h:307:9: note: in expansion of macro â€˜__underlying_strncpy’
 307 | return __underlying_strncpy(p, q, size);
 | ^~~~~~~~~~~~~~~~~~~~

Link: https://lore.kernel.org/r/20201102102544.1018706-1-lee.jones@linaro.org
Cc: support@areca.com.tw
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: Allow an error return value from ->device_reset()
Adrian Hunter [Tue, 3 Nov 2020 14:14:03 +0000 (16:14 +0200)]
scsi: ufs: Allow an error return value from ->device_reset()

It is simpler for drivers to provide a ->device_reset() callback
irrespective of whether the GPIO, or firmware interface necessary to do the
reset, is discovered during probe.

Change ->device_reset() to return an error code.  Drivers that provide the
callback, but do not do the reset operation should return -EOPNOTSUPP.

Link: https://lore.kernel.org/r/20201103141403.2142-3-adrian.hunter@intel.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Bean huo <beanhuo@micron.com>
Reviewed-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: ufs: Add DeepSleep feature
Adrian Hunter [Tue, 3 Nov 2020 14:14:02 +0000 (16:14 +0200)]
scsi: ufs: Add DeepSleep feature

DeepSleep is a UFS v3.1 feature that achieves the lowest power consumption
of the device, apart from power off.

In DeepSleep mode, no commands are accepted, and the only way to exit is
using a hardware reset or power cycle.

This patch assumes that if a power cycle was an option, then power off
would be preferable, so only exit via a hardware reset is supported.

Drivers that wish to support DeepSleep need to set a new capability flag
UFSHCD_CAP_DEEPSLEEP and provide a hardware reset via the existing
 ->device_reset() callback.

It is assumed that UFS devices with wspecversion >= 0x310 support
DeepSleep.

[mkp: dropped sysfs ABI doc due to conflicts]

Link: https://lore.kernel.org/r/20201103141403.2142-2-adrian.hunter@intel.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Can Guo <cang@codeaurora.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: pm80xx: Fix pm8001_mpi_get_nvmd_resp() race condition
yuuzheng [Mon, 2 Nov 2020 16:55:28 +0000 (22:25 +0530)]
scsi: pm80xx: Fix pm8001_mpi_get_nvmd_resp() race condition

A use-after-free or null-pointer error occurs when the 251-byte response
data is copied from IOMB buffer to response message buffer in function
pm8001_mpi_get_nvmd_resp().

After sending the command get_nvmd_data(), the caller begins to sleep by
calling wait_for_complete() and waits for the wake-up from calling
complete() in pm8001_mpi_get_nvmd_resp(). Due to unexpected events (e.g.,
interrupt), if response buffer gets freed before memcpy(), a use-after-free
error will occur. To fix this, the complete() should be called after
memcpy().

Link: https://lore.kernel.org/r/20201102165528.26510-5-Viswas.G@microchip.com.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: yuuzheng <yuuzheng@google.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Radha Ramachandran <radha@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: pm80xx: Avoid busywait in FW ready check
akshatzen [Mon, 2 Nov 2020 16:55:27 +0000 (22:25 +0530)]
scsi: pm80xx: Avoid busywait in FW ready check

In function check_fw_ready() we busy wait using udelay. The CPU is not
released and we see need_resched failures.

Busy waiting is not necessary since we are in process context and we can
sleep instead. Replace udelay with msleep of 20 ms intervals while waiting
for firmware to become ready.

It has been verified that check_fw_ready is not being used in interrupt
context anywhere, hence it is safe to make this change.

Link: https://lore.kernel.org/r/20201102165528.26510-4-Viswas.G@microchip.com.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: akshatzen <akshatzen@google.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Radha Ramachandran <radha@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: pm80xx: Make running_req atomic
Viswas G [Mon, 2 Nov 2020 16:55:26 +0000 (22:25 +0530)]
scsi: pm80xx: Make running_req atomic

Incorrect value of the running_req was causing the driver unload to be
stuck during the SAS lldd_dev_gone notification handling.  During SATA I/O
completion, for some error status values, the driver schedules the event
handler and running_req is decremented from that.  However, there are some
other error status values (like IO_DS_IN_RECOVERY,
IO_XFER_ERR_LAST_PIO_DATAIN_CRC_ERR) where the I/O has already been
completed by fw/driver so running_req is not decremented.

Also during NCQ error handling, driver itself will initiate READ_LOG_EXT
and ABORT_ALL. When libsas/libata initiate READ_LOG_EXT (0x2F), driver
increments running_req. This will be completed by the driver in
pm80xx_chip_sata_req(), but running_req was not decremented.

Link: https://lore.kernel.org/r/20201102165528.26510-3-Viswas.G@microchip.com.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: pm80xx: Make mpi_build_cmd locking consistent
peter chang [Mon, 2 Nov 2020 16:55:25 +0000 (22:25 +0530)]
scsi: pm80xx: Make mpi_build_cmd locking consistent

Driver submits all internal requests (like abort_task, event acknowledgment
etc.) through inbound queue 0. While submitting those, driver does not
acquire any lock and this may lead to a race when there is an I/O request
coming in on CPU0 and submitted through inbound queue 0.  To avoid this,
lock acquisition has been moved to pm8001_mpi_build_cmd().  All command
submission will go through this path.

Link: https://lore.kernel.org/r/20201102165528.26510-2-Viswas.G@microchip.com.com
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: peter chang <dpf@google.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com>
Signed-off-by: Radha Ramachandran <radha@google.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: tcm_loop: Allow queues, can_queue and cmd_per_lun to be settable
Mike Christie [Sun, 1 Nov 2020 18:59:34 +0000 (12:59 -0600)]
scsi: tcm_loop: Allow queues, can_queue and cmd_per_lun to be settable

Make can_queue, nr_hw_queues and cmd_per_lun settable by the user instead
of hard coding them.

Link: https://lore.kernel.org/r/1604257174-4524-9-git-send-email-michael.christie@oracle.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Make state_list per CPU
Mike Christie [Sun, 1 Nov 2020 18:59:33 +0000 (12:59 -0600)]
scsi: target: Make state_list per CPU

Do a state_list/execute_task_lock per CPU, so we can do submissions from
different CPUs without contention with each other.

Note: tcm_fc was passing TARGET_SCF_USE_CPUID, but never set cpuid.  The
assumption is that it wanted to set the cpuid to the CPU it was submitting
from so it will get this behavior with this patch.

[mkp: s/printk/pr_err/ + resolve COMPARE AND WRITE patch conflict]

Link: https://lore.kernel.org/r/1604257174-4524-8-git-send-email-michael.christie@oracle.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Drop sess_cmd_lock from I/O path
Mike Christie [Sun, 1 Nov 2020 18:59:32 +0000 (12:59 -0600)]
scsi: target: Drop sess_cmd_lock from I/O path

Drop the sess_cmd_lock by:

 - Removing the sess_cmd_list use from LIO core, because it's been
   moved to qla2xxx.

 - Removing sess_tearing_down check in the I/O path. Instead of using that
   bit and the sess_cmd_lock, we rely on the cmd_count percpu ref. To do
   this we switch to percpu_ref_kill_and_confirm/percpu_ref_tryget_live.

Link: https://lore.kernel.org/r/1604257174-4524-7-git-send-email-michael.christie@oracle.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: qla2xxx: Move sess cmd list/lock to driver
Mike Christie [Sun, 1 Nov 2020 18:59:31 +0000 (12:59 -0600)]
scsi: qla2xxx: Move sess cmd list/lock to driver

Except for debug output in the shutdown path, tcm_qla2xxx is the only
driver using the se_session sess_cmd_list. Move the list to that driver to
facilitate removing the sess_cmd_lock from the main I/O path for the rest
of the drivers.

Link: https://lore.kernel.org/r/1604257174-4524-6-git-send-email-michael.christie@oracle.com
Cc: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Remove TARGET_SCF_LOOKUP_LUN_FROM_TAG
Mike Christie [Sun, 1 Nov 2020 18:59:30 +0000 (12:59 -0600)]
scsi: target: Remove TARGET_SCF_LOOKUP_LUN_FROM_TAG

TARGET_SCF_LOOKUP_LUN_FROM_TAG is no longer used so remove it.

Link: https://lore.kernel.org/r/1604257174-4524-5-git-send-email-michael.christie@oracle.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG
Mike Christie [Sun, 1 Nov 2020 18:59:29 +0000 (12:59 -0600)]
scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG

Only the __qlt_24xx_handle_abts() code path does not know the LUN for an
abort and it uses the TARGET_SCF_LOOKUP_LUN_FROM_TAG flag to have LIO core
look it up. LIO uses target_lookup_lun_from_tag to go from cmd tag to LUN
for the driver. However, qla2xxx has a tcm_qla2xxx_find_cmd_by_tag() which
does almost the same thing as the LIO helper (it finds the cmd but does not
return the LUN). This patch has qla2xxx use its internal helper.

Link: https://lore.kernel.org/r/1604257174-4524-4-git-send-email-michael.christie@oracle.com
Cc: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Fix cmd_count ref leak
Mike Christie [Sun, 1 Nov 2020 18:59:28 +0000 (12:59 -0600)]
scsi: target: Fix cmd_count ref leak

percpu_ref_init sets the refcount to 1 and percpu_ref_kill drops it.
Drivers like iSCSI and loop do not call target_sess_cmd_list_set_waiting
during session shutdown, though, so they have been calling percpu_ref_exit
with a refcount still taken and leaking the cmd_counts memory.

Link: https://lore.kernel.org/r/1604257174-4524-3-git-send-email-michael.christie@oracle.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Fix LUN ref count handling
Mike Christie [Sun, 1 Nov 2020 18:59:27 +0000 (12:59 -0600)]
scsi: target: Fix LUN ref count handling

Fix two bugs in the LUN refcounting:

 1. For the TCM_WRITE_PROTECTED case we were returning an error after
    taking a ref to the LUN, but never dropping it (caller just send status
    and drops cmd ref).

 2. We still need to do a percpu_ref_tryget_live for the virt LUN 0 like we
    do for other LUNs, because the TPG code does the refcount/wait process
    like it does with other LUNs.

Link: https://lore.kernel.org/r/1604257174-4524-2-git-send-email-michael.christie@oracle.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: fcoe: Remove unneeded semicolon
Tom Rix [Sun, 1 Nov 2020 14:40:17 +0000 (06:40 -0800)]
scsi: fcoe: Remove unneeded semicolon

A semicolon is not needed after a switch statement.

Link: https://lore.kernel.org/r/20201101144017.2284047-1-trix@redhat.com
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: bnx2fc: Remove unneeded semicolon
Tom Rix [Sun, 1 Nov 2020 14:38:12 +0000 (06:38 -0800)]
scsi: bnx2fc: Remove unneeded semicolon

A semicolon is not needed after a switch statement.

Link: https://lore.kernel.org/r/20201101143812.2283642-1-trix@redhat.com
Reviewed-by: Saurav Kashyap <skashyap@marvell.com>
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Return COMPARE AND WRITE miscompare offsets
David Disseldorp [Sat, 31 Oct 2020 23:32:11 +0000 (00:32 +0100)]
scsi: target: Return COMPARE AND WRITE miscompare offsets

SBC-4 r15 5.3 COMPARE AND WRITE command states:
  if the compare operation does not indicate a match, then terminate the
  command with CHECK CONDITION status with the sense key set to
  MISCOMPARE and the additional sense code set to MISCOMPARE DURING
  VERIFY OPERATION. In the sense data (see 4.18 and SPC-5) the offset
  from the start of the Data-Out Buffer to the first byte of data that
  was not equal shall be reported in the INFORMATION field.

This change implements the missing logic to report the miscompare offset in
the sense data INFORMATION field. As an optimization, byte-by-byte
miscompare offset calculation is only performed after memcmp() mismatch.

Link: https://lore.kernel.org/r/20201031233211.5207-5-ddiss@suse.de
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Split out COMPARE AND WRITE memcmp into helper
David Disseldorp [Sat, 31 Oct 2020 23:32:10 +0000 (00:32 +0100)]
scsi: target: Split out COMPARE AND WRITE memcmp into helper

In preparation for finding and returning the miscompare offset.

Link: https://lore.kernel.org/r/20201031233211.5207-4-ddiss@suse.de
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Rename cmd.bad_sector to cmd.sense_info
David Disseldorp [Sat, 31 Oct 2020 23:32:09 +0000 (00:32 +0100)]
scsi: target: Rename cmd.bad_sector to cmd.sense_info

cmd.bad_sector currently gets packed into the sense INFORMATION field for
TCM_LOGICAL_BLOCK_{GUARD,APP_TAG,REF_TAG}_CHECK_FAILED errors, which carry
an .add_sector_info flag in the sense_detail_table to ensure this.

In preparation for propagating a byte offset on COMPARE AND WRITE
TCM_MISCOMPARE_VERIFY error, rename cmd.bad_sector to cmd.sense_info and
sense_detail.add_sector_info to sense_detail.add_sense_info so that it
better reflects the sense INFORMATION field destination.

[ddiss: update previously overlooked ib_isert]

Link: https://lore.kernel.org/r/20201031233211.5207-3-ddiss@suse.de
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: target: Rename struct sense_info to sense_detail
David Disseldorp [Sat, 31 Oct 2020 23:32:08 +0000 (00:32 +0100)]
scsi: target: Rename struct sense_info to sense_detail

This helps distinguish it from the SCSI sense INFORMATION field.

Link: https://lore.kernel.org/r/20201031233211.5207-2-ddiss@suse.de
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: megaraid_sas: Simplify compat_ioctl handling
Arnd Bergmann [Fri, 30 Oct 2020 16:44:21 +0000 (17:44 +0100)]
scsi: megaraid_sas: Simplify compat_ioctl handling

There have been several attempts to fix serious problems in the compat
handling in megasas_mgmt_compat_ioctl_fw(), and it also uses the
compat_alloc_user_space() function.

Folding the compat handling into the regular ioctl function with
in_compat_syscall() simplifies it a lot and avoids some of the remaining
problems:

 - missing handling of unaligned pointers

 - overflowing the ioc->frame.raw array from invalid input

 - compat_alloc_user_space()

Link: https://lore.kernel.org/r/20201030164450.1253641-3-arnd@kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: megaraid_sas: Check user-provided offsets
Arnd Bergmann [Fri, 30 Oct 2020 16:44:20 +0000 (17:44 +0100)]
scsi: megaraid_sas: Check user-provided offsets

It sounds unwise to let user space pass an unchecked 32-bit offset into a
kernel structure in an ioctl. This is an unsigned variable, so checking the
upper bound for the size of the structure it points into is sufficient to
avoid data corruption, but as the pointer might also be unaligned, it has
to be written carefully as well.

While I stumbled over this problem by reading the code, I did not continue
checking the function for further problems like it.

Link: https://lore.kernel.org/r/20201030164450.1253641-2-arnd@kernel.org
Fixes: c4a3e0a529ab ("[SCSI] MegaRAID SAS RAID: new driver")
Cc: <stable@vger.kernel.org> # v2.6.15+
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: aacraid: Improve compat_ioctl handlers
Arnd Bergmann [Fri, 30 Oct 2020 16:44:19 +0000 (17:44 +0100)]
scsi: aacraid: Improve compat_ioctl handlers

The use of compat_alloc_user_space() can be easily replaced by handling
compat arguments in the regular handler, and this will make it work for
big-endian kernels as well, which at the moment get an invalid indirect
pointer argument.

Calling aac_ioctl() instead of aac_compat_do_ioctl() means the compat and
native code paths behave the same way again, which they stopped when the
adapter health check was added only in the native function.

Link: https://lore.kernel.org/r/20201030164450.1253641-1-arnd@kernel.org
Fixes: 572ee53a9bad ("scsi: aacraid: check adapter health")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Bump driver version to 35.101.00.00
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:47 +0000 (18:38 +0530)]
scsi: mpt3sas: Bump driver version to 35.101.00.00

Bump mpt3sas driver version to 35.101.00.00

Link: https://lore.kernel.org/r/20201027130847.9962-15-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Add module parameter multipath_on_hba
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:46 +0000 (18:38 +0530)]
scsi: mpt3sas: Add module parameter multipath_on_hba

Add module parameter multipath_on_hba to enable/disable multi-port path
topology support.  By default this feature is enabled on SAS3.5 HBA device
and disabled on SAS3 &SAS2.5 HBA devices.

When this feature is disabled then driver uses a default
PhysicalPort(PortID) number i.e. 255 instead of the PhysicalPort number
provided by HBA firmware.

Link: https://lore.kernel.org/r/20201027130847.9962-14-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Handle vSES vphy object during HBA reset
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:45 +0000 (18:38 +0530)]
scsi: mpt3sas: Handle vSES vphy object during HBA reset

During HBA reset the Port ID of vSES device may change. As a result, it is
necessary to refresh virtual_phy objects after reset.

Each Port's vphy_list table needs to be updated after updating the
HBA port table. The algorithm is as follows:

 - Loop over each port entry from HBA port table
   * Loop over each virtual phy entry from port's vphys_list table
     - Mark virtual phy entry as dirty by setting dirty bit in virtual phy
       entry's flags field
 - Read SASIOUnitPage0 page
 - Loop over each HBA Phy's Phy data from SASIOUnitPage0
    * If phy's remote attached device is not SES device then continue with
      processing next HBA Phy's Phy data;
    * Read SASPhyPage0 data for this Phy number and determine whether
      current phy is a virtual phy or not. If it is not a virtual phy then
      continue with next Phy data;
    * Get the current phy's remote attached vSES device's SAS Address;
    * Loop over each port entry from HBA port table
      - If Port's vphys_mask field is zero then continue with
        next Port entry,
      - Loop over each virtual phy entry from Port's vphy_list table
      - If the current phy's remote SAS Address is different from
        virtual phy entry's SAS Address then continue with next
        virtual phy entry,
      - Set bit corresponding to current phy number in virtual phy
        entry's phy_mask field,
      - Get the HBA port table's Port entry corresponding to
        Phy data's 'Port' value,
        * If there is no Port entry corresponding to Phy data's
 'Port' value in HBA port table then create a new port entry
 and add it to HBA port table.
      - If this retrieved Port entry is the same as the current Port
        entry then don't do anything, just clear the dirty bit from
        virtual phy entry's flag field and continue with processing
        next HBA Phy's Phy data.
      - If this retrieved Port entry is different from the current Port
        entry then move the current virtual phy entry from current Port's
        vphys_list to retrieved Port entry's vphys_list.
        * Clear current phy bit in current Port entry's vphys_mask and
          set the current phy bit in the retrieved Port entry's
          vphys_mask field.
        * Clear the dirty bit from virtual phy entry's flag field and
          continue with next HBA Phy's Phy data.
 - Delete the 'virtual phy' entries and HBA's 'Port table' entries which
   are still marked as 'dirty'.

Link: https://lore.kernel.org/r/20201027130847.9962-13-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Add bypass_dirty_port_flag parameter
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:44 +0000 (18:38 +0530)]
scsi: mpt3sas: Add bypass_dirty_port_flag parameter

Added a new parameter bypass_dirty_port_flag in function
mpt3sas_get_port_by_id(). When this parameter is set to one then search for
matching hba port entry from port_table_list even when this hba_port entry
is marked as dirty.

Link: https://lore.kernel.org/r/20201027130847.9962-12-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Handling HBA vSES device
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:43 +0000 (18:38 +0530)]
scsi: mpt3sas: Handling HBA vSES device

Each direct attached device will have a unique Port ID, but with an
exception. HBA vSES may use the same Port ID of another direct attached
device Port's ID. As a result, special handling is needed for vSES.

Create a virtual_phy object when a new HBA vSES device is detected and add
this virtual_phy object to vphys_list of port ID's hba_port object.  When
the HBA vSES device is removed then remove the corresponding virtual_phy
object from its parent's hba_port's vphy_list and free this virtual_vphy
object.

In hba_port object add vphy_mask field to hold the list of HBA phy bits
which are assigned to vSES devices. Also add vphy_list list to hold list of
virtual_phy objects which holds the same portID of current hba_port's
portID.

Also, add a hba_vphy field in _sas_phy object to determine whether this
_sas_phy object belongs to vSES device or not.

 - Allocate a virtual_phy object whenever a virtual phy is detected while
   processing the SASIOUnitPage0's phy data. And this allocated virtual_phy
   object to corresponding PortID's hba_port's vphy_list.

 - When a vSES device is added to the SML then initialize the corresponding
   virtual_phy objects's sas_address field with vSES device's SAS Address.

 - Free this virtual_phy object during driver unload time and when this
   vSES device is removed.

Link: https://lore.kernel.org/r/20201027130847.9962-11-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Set valid PhysicalPort in SMPPassThrough
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:42 +0000 (18:38 +0530)]
scsi: mpt3sas: Set valid PhysicalPort in SMPPassThrough

The driver currently sets PhysicalPort field to 0xFF for SMPPassthrough
Request message. In zoning topologies this SMPPassthrough command always
operates on devices in one zone (default zone) even when user issues SMP
command for other zone drives.

Define _transport_get_port_id_by_rphy() and
_transport_get_port_id_by_sas_phy() helper functions to get Physical Port
number from sas_rphy & sas_phy respectively for SMPPassthrough request
message so that SMP Passthrough request message is sent to intended zone
device.

Link: https://lore.kernel.org/r/20201027130847.9962-10-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Update hba_port objects after host reset
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:41 +0000 (18:38 +0530)]
scsi: mpt3sas: Update hba_port objects after host reset

During host reset there is a chance that the Port number allocated by the
firmware for the attached devices may change. Also, it may be possible that
some HBA phy's can go down/come up after reset. As a result, the driver
can't just trust the HBA Port table that it has populated before host reset
as valid. Instead it has to update the HBA Port table in such a way that it
shouldn't disturb the drives which are still accessible even after host
reset.

Use the following algorithm to update the HBA Port table during host reset:

I. After host reset operation and before marking the devices as
   responding/non-responding, create a temporary Port table called "New
   Port table" by parsing each of the HBA phy's Phy data info read from SAS
   IOUnit Page0:

   a. Check whether Phy's negotiated link rate is greater than 1.5Gbps, if
      not go to next Phy;

   b. Get the SAS Address of the attached device;

   c. Create a new entry in the "New Port table" with SAS Address field
      filled with attached device's SAS Address, port number with Phy's
      Port number (read from SAS IOUnit Page0) and enable bit in the 'Phy
      mask' field corresponding to current Phy number.  New entry is
      created only if the driver can't find an entry in the "New Port
      table" which matches with attached device 'SAS Address' & 'Port
      Number'. If it finds an entry with matches with attached device 'SAS
      Address' & 'Port Number' then the driver takes that matched entry and
      will enable current Phy number bit in the 'Phy mask' field;

   d. After parsing all the HBA phy's info, the driver will have complete
      Port table info in "New Port table".

II. Mark all the existing sas_device & sas_expander device structures as
    'dirty'.

III. Mark each entry of the HBA Port lists as 'dirty'.

IV. Take each entry from 'New Port table' one by one and check whether the
    entry has any corresponding matched entry (which is marked as 'dirty')
    in the HBA Port table or not.  While looking for a corresponding
    matched entry, look for matched entry in the sequence from top row to
    bottom row listed in the following table. If you find any matched entry
    (according to any of the rules tabulated below) then perform the action
    mentioned in the 'Action' column in that matched rule.

    ===========================================================================
    |Search  |SAS     | Phy Mask | Port    | Possibilities| Action            |
    |every   |Address |    or    | Number  |              | required          |
    |entry   |matched?| subset of| matched?|              |                   |
    |in below|        | phy mask |         |              |                   |
    |sequence|        | matched? |         |              |                   |
    ===========================================================================
    |  1     |matched | matched  | matched | nothing      |* unmark HBA port  |
    |        |        |          |         | changed      |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  2     |matched | matched  | not     | port number  |* Update port      |
    |        |        |          | matched | is changed   |number in the      |
    |        |        |          |         |              |matched port table |
    |        |        |          |         |              |entry              |
    |        |        |          |         |              |* unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  3.a   |matched | subset of| matched |some phys     |* Add these new    |
    |        |        | phy mask | (or)    |might have    |phys to current    |
    |        |        | matched  | not     |enabled which |port in STL        |
    |        |        |          | matched |are previously|* Update phy mask  |
    |        |        |          | (but    |disabled      |field in HBA's port|
    |        |        |          | first   |              |table's matched    |
    |        |        |          | look for|              |entry,             |
    |        |        |          | matched |              |* Update port      |
    |        |        |          | one)    |              |number in the      |
    |      |       |  |     |   |matched port       |
    |        |        |          |         |              |table entry (if    |
    |        |        |          |         |              |port number is     |
    |        |        |          |         |              |changed),          |
    |        |        |          |         |              |* Unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  3.b   |matched | subset of| matched |some phys     |*Remove these phys |
    |        |        | phy mask | (or)    |might have    |from current port  |
    |        |        | matched  | not     |disabled which|in STL             |
    |        |        |          | matched |are previously|* Update phy mask  |
    |        |        |          | (but    |enabled       |field in HBA's port|
    |        |        |          | first   |              |tables's matched   |
    |        |        |          | look for|              |entry,             |
    |        |        |          | matched |              |*Update port number|
    |        |        |          | one)    |              |in the matched port|
    |        |        |          |         |              |table entry (if    |
    |        |        |          |         |              |port number is     |
    |        |        |          |         |              |changed),          |
    |        |        |          |         |              |* Unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------
    |  4     |matched | not      | matched |A cable       |*Remove old phys & |
    |        |        | matched  | (or)    |attached to an|new phys to current|
    |        |        |          | not     |expander is   |port in STL        |
    |        |        |          | matched |changed to    |* Update phy mask  |
    |        |        |          |         |another HBA   |field in HBA's port|
    |        |        |          |         |port during   |tables's matched   |
    |        |        |          |         |reset         |entry,             |
    |        |        |          |         |              |*Update port number|
    |        |        |          |         |              |in the matched port|
    |        |        |          |         |              |table entry (if    |
    |        |        |          |         |              |port number is     |
    |        |        |          |         |              |changed),          |
    |        |        |          |         |              |* Unmask HBA port  |
    |        |        |          |         |              |table entry as     |
    |        |        |          |         |              |dirty              |
    ---------------------------------------------------------------------------

V. Delete the hba_port objects which are still marked as dirty.

Link: https://lore.kernel.org/r/20201027130847.9962-9-sreekanth.reddy@broadcom.com
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Get sas_device objects using device's rphy
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:40 +0000 (18:38 +0530)]
scsi: mpt3sas: Get sas_device objects using device's rphy

In the following scsi_host_template and sas_function_template callback
functions the driver does not have PhysicalPort number information to
retrieve the sas_device object using SAS Address & PhysicalPort number. In
these callback functions the device's rphy object is used to retrieve
sas_device object for the device.

.target_alloc,
.get_enclosure_identifier
.get_bay_identifier

When a rphy (of type sas_rphy) object is allocated then its address is
saved in corresponding sas_device object's rphy field. In
__mpt3sas_get_sdev_by_rphy(), the driver loops over all the sas_device
objects from sas_device_list list to retrieve the sas_device objects whose
rphy matches the provided rphy.

Link: https://lore.kernel.org/r/20201027130847.9962-8-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Rename transport_del_phy_from_an_existing_port()
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:39 +0000 (18:38 +0530)]
scsi: mpt3sas: Rename transport_del_phy_from_an_existing_port()

Renamed _transport_add_phy_to_an_existing_port() to
mpt3sas_transport_add_phy_to_an_existing_port() and
_transport_del_phy_from_an_existing_port() to
mpt3sas_transport_del_phy_from_an_existing_port() as the driver needs to
call these functions from outside mpt3sas_transport.c file.

Added extra function argument 'port' of type struct hba_port to above
functions and check for portID before adding/removing the phy from the
_sas_port object.  I.e. add/remove the phy from _sas_port object only if
_sas_port's port object and phy's port object are the same.

Link: https://lore.kernel.org/r/20201027130847.9962-7-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Get device objects using sas_address & portID
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:38 +0000 (18:38 +0530)]
scsi: mpt3sas: Get device objects using sas_address & portID

Currently driver retrieves the sas_device/sas_expander objects from
corresponding object's lists using just device's SAS Address.

Make driver retrieve the objects from the corresponding objects list using
device's SAS Address and PhysicalPort (or PortID) number. PhysicalPort
number is the port number of the HBA through which this device is accessed.

Link: https://lore.kernel.org/r/20201027130847.9962-6-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
3 years agoscsi: mpt3sas: Update hba_port's sas_address & phy_mask
Sreekanth Reddy [Tue, 27 Oct 2020 13:08:37 +0000 (18:38 +0530)]
scsi: mpt3sas: Update hba_port's sas_address & phy_mask

Update hba_port's sas_address & phy_mask fields whenever a direct expander
or sas/sata target devices are added or removed.

When any direct attached device is discovered then driver:

 - Gets the hba_port object corresponding to device's PhysicalPort
   number;

 - Updates the hba_port's sas_address field with device's SAS
   Address;

 - Updates the hba_port's phy_mask filed with device's narrow/wide
   port Phy number bits;

 - If a sas/sata end device (not only direct-attached devices) is added
   then corresponding sas_device object's port variable is assigned with
   hba_port object's address whose port_id matches the device's
   PhysicalPort number.

 - If an expander device is added then corresponding sas_expander object's
   port variable is assigned with hba_port object's address whose port_id
   matches the expander device's PhysicalPort number.

When any direct attached device is detached then driver will delete the
hba_port object corresponding to device's PhysicalPort number.

Whenever any HBA phy's link (of direct attached device's port) comes up
then update the phy_mask field of corresponding hba_port object.

Link: https://lore.kernel.org/r/20201027130847.9962-5-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>