scsi: scsi_debug: Fix an error handling bug in sdeb_zbc_model_str()

This test is checking the wrong variable.  It should be testing "res".
The "sdeb_zbc_model" variable is an enum (unsigned in this situation)
and we never assign negative values to it.

[mkp: fixed commit desc issue reported by Doug]

Link: https://lore.kernel.org/r/20200509100408.GA5555@mwanda
Fixes: 9267e0eb41fe ("scsi: scsi_debug: Add ZBC module parameter")
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Move allocation of the shost object to after xconf- and xport-data

At the moment we allocate and register the Scsi_Host object corresponding
to a zfcp adapter (FCP device) very early in the life cycle of the adapter
- even before we fully discover and initialize the underlying
firmware/hardware. This had the advantage that we could already use the
Scsi_Host object, and fill in all its information during said discover and
initialize.

Due to commit 737eb78e82d5 ("block: Delay default elevator initialization")
(first released in v5.4), we noticed a regression that would prevent us
from using any storage volume if zfcp is configured with support for DIF or
DIX (zfcp.dif=1 || zfcp.dix=1). Doing so would result in an illegal memory
access as soon as the first request is sent with such an configuration. As
example for a crash resulting from this:

  scsi host0: scsi_eh_0: sleeping
  scsi host0: zfcp
  qdio: 0.0.1900 ZFCP on SC 4bd using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA: W AP
  scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36
  Unable to handle kernel pointer dereference in virtual kernel address space
  Failing address: 0000000000000000 TEID: 0000000000000483
  Fault in home space mode while using kernel ASCE.
  AS:0000000035c7c007 R3:00000001effcc007 S:00000001effd1000 P:000000000000003d
  Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC
  Modules linked in: ...
  CPU: 1 PID: 783 Comm: kworker/u760:5 Kdump: loaded Not tainted 5.6.0-rc2-bb-next+ #1
  Hardware name: ...
  Workqueue: scsi_wq_0 fc_scsi_scan_rport [scsi_transport_fc]
  Krnl PSW : 0704e00180000000 000003ff801fcdae (scsi_queue_rq+0x436/0x740 [scsi_mod])
             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
  Krnl GPRS: 0fffffffffffffff 0000000000000000 0000000187150120 0000000000000000
             000003ff80223d20 000000000000018e 000000018adc6400 0000000187711000
             000003e0062337e8 00000001ae719000 0000000187711000 0000000187150000
             00000001ab808100 0000000187150120 000003ff801fcd74 000003e0062336a0
  Krnl Code: 000003ff801fcd9e: e310a35c0012        lt      %r1,860(%r10)
             000003ff801fcda4: a7840010           brc     8,000003ff801fcdc4
            #000003ff801fcda8: e310b2900004       lg      %r1,656(%r11)
            >000003ff801fcdae: d71710001000       xc      0(24,%r1),0(%r1)
             000003ff801fcdb4: e310b2900004       lg      %r1,656(%r11)
             000003ff801fcdba: 41201018           la      %r2,24(%r1)
             000003ff801fcdbe: e32010000024       stg     %r2,0(%r1)
             000003ff801fcdc4: b904002b           lgr     %r2,%r11
  Call Trace:
   [<000003ff801fcdae>] scsi_queue_rq+0x436/0x740 [scsi_mod]
  ([<000003ff801fcd74>] scsi_queue_rq+0x3fc/0x740 [scsi_mod])
   [<00000000349c9970>] blk_mq_dispatch_rq_list+0x390/0x680
   [<00000000349d1596>] blk_mq_sched_dispatch_requests+0x196/0x1a8
   [<00000000349c7a04>] __blk_mq_run_hw_queue+0x144/0x160
   [<00000000349c7ab6>] __blk_mq_delay_run_hw_queue+0x96/0x228
   [<00000000349c7d5a>] blk_mq_run_hw_queue+0xd2/0xe0
   [<00000000349d194a>] blk_mq_sched_insert_request+0x192/0x1d8
   [<00000000349c17b8>] blk_execute_rq_nowait+0x80/0x90
   [<00000000349c1856>] blk_execute_rq+0x6e/0xb0
   [<000003ff801f8ac2>] __scsi_execute+0xe2/0x1f0 [scsi_mod]
   [<000003ff801fef98>] scsi_probe_and_add_lun+0x358/0x840 [scsi_mod]
   [<000003ff8020001c>] __scsi_scan_target+0xc4/0x228 [scsi_mod]
   [<000003ff80200254>] scsi_scan_target+0xd4/0x100 [scsi_mod]
   [<000003ff802d8b96>] fc_scsi_scan_rport+0x96/0xc0 [scsi_transport_fc]
   [<0000000034245ce8>] process_one_work+0x458/0x7d0
   [<00000000342462a2>] worker_thread+0x242/0x448
   [<0000000034250994>] kthread+0x15c/0x170
   [<0000000034e1979c>] ret_from_fork+0x30/0x38
  INFO: lockdep is turned off.
  Last Breaking-Event-Address:
   [<000003ff801fbc36>] scsi_add_cmd_to_list+0x9e/0xa8 [scsi_mod]
  Kernel panic - not syncing: Fatal exception: panic_on_oops

While this issue is exposed by the commit named above, this is only by
accident. The real issue exists for longer already - basically since it's
possible to use blk-mq via scsi-mq, and blk-mq pre-allocates all requests
for a tag-set during initialization of the same. For a given Scsi_Host
object this is done when adding the object to the midlayer
(`scsi_add_host()` and such). In `scsi_mq_setup_tags()` the midlayer
calculates how much memory is required for a single scsi_cmnd, and its
additional data, which also might include space for additional protection
data - depending on whether the Scsi_Host has any form of protection
capabilities (`scsi_host_get_prot()`).

The problem is now thus, because zfcp does this step before we actually
know whether the firmware/hardware has these capabilities, we don't set any
protection capabilities in the Scsi_Host object. And so, no space is
allocated for additional protection data for requests in the Scsi_Host
tag-set.

Once we go through discover and initialize the FCP device firmware/hardware
fully (this is done via the firmware commands "Exchange Config Data" and
"Exchange Port Data") we find out whether it actually supports DIF and DIX,
and we set the corresponding capabilities in the Scsi_Host object (in
`zfcp_scsi_set_prot()`). Now the Scsi_Host potentially has protection
capabilities, but the already allocated requests in the tag-set don't have
any space allocated for that.

When we then trigger target scanning or add scsi_devices manually, the
midlayer will use requests from that tag-set, and before sending most
requests, it will also call `scsi_mq_prep_fn()`. To prepare the scsi_cmnd
this function will check again whether the used Scsi_Host has any
protection capabilities - and now it potentially has - and if so, it will
try to initialize the assumed to be preallocated structures and thus it
causes the crash, like shown above.

Before delaying the default elevator initialization with the commit named
above, we always would also allocate an elevator for any scsi_device before
ever sending any requests - in contrast to now, where we do it after
device-probing. That elevator in turn would have its own tag-set, and that
is initialized after we went through discovery and initialization of the
underlying firmware/hardware. So requests from that tag-set can be
allocated properly, and if used - unless the user changes/disabled the
default elevator - this would hide the underlying issue.

To fix this for any configuration - with or without an elevator - we move
the allocation and registration of the Scsi_Host object for a given FCP
device to after the first complete discovery and initialization of the
underlying firmware/hardware. By doing that we can make all basic
properties of the Scsi_Host known to the midlayer by the time we call
`scsi_add_host()`, including whether we have any protection capabilities.

To do that we have to delay all the accesses that we would have done in the
past during discovery and initialization, and do them instead once we are
finished with it. The previous patches ramp up to this by fencing and
factoring out all these accesses, and make it possible to re-do them later
on. In addition we make also use of the diagnostic buffers we recently
added with

commit 92953c6e0aa7 ("scsi: zfcp: signal incomplete or error for sync exchange config/port data")
commit 7e418833e689 ("scsi: zfcp: diagnostics buffer caching and use for exchange port data")
commit 088210233e6f ("scsi: zfcp: add diagnostics buffer for exchange config data")

(first released in v5.5), because these already cache all the information
we need for that "re-do operation" - the information cached are always
updated during xconf or xport data, so it won't be stale.

In addition to the move and re-do, this patch also updates the
function-documentation of `zfcp_scsi_adapter_register()` and changes how it
reports if a Scsi_Host object already exists. In that case future
recovery-operations can skip this step completely and behave much like they
would do in the past - zfcp does not release a once allocated Scsi_Host
object unless the corresponding FCP device is deconstructed completely.

Link: https://lore.kernel.org/r/030dd6da318bbb529f0b5268ec65cebcd20fc0a3.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Fence early sysfs interfaces for accesses of shost objects

When setting an adapter online for the first time, we also create a couple
of entries for it in the sysfs device tree. This is also true even if the
adapter has not yet ever gone successfully through exchange config and
exchange port data.

When moving the scsi host object allocation and registration to after the
first exchange config and exchange port data, this make the `port_rescan`
attribute susceptible to invalid pointer-dereferences of the shost field
before the adapter is fully initialized.

When written to, it schedules a `scan_work` item that will in turn make use
of the associated fibre channel host object to check the topology used for
this FCP device.

Because scanning for remote ports can't be done successfully without
completing exchange config and exchange port data first, we can simply
fence `port_rescan`, and so prevent the illegal access.

As with cases where we can't get a reference to the adapter, we also return
-ENODEV here. Applications need to handle that errno today already.

After a successful allocation of the scsi host object nothing changes in
the work flow.

Link: https://lore.kernel.org/r/ef65366d309993ca91b6917727590ca7ca166c8f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Fence adapter status propagation for common statuses

Common status flags that all main objects - adapter, port, and unit -
support are propagated to sub-objects when set or cleared. For instance,
when setting the status ZFCP_STATUS_COMMON_ERP_INUSE for an adapter object,
we will propagate this to all its child ports and units - same for when
clearing a common status flag.

Units of an adapter object are enumerated via __shost_for_each_device()
over the scsi host object of the corresponding adapter.

Once we move the scsi host object allocation and registration to after the
first exchange config and exchange port data, this won't be possible for
cases where we set or clear common statuses during the very first adapter
recovery.

But since we won't have any port or unit objects yet at that point of time,
we can just fence the status propagation for cases where the scsi host
object is not yet set in the adapter object. It won't change any effective
status propagations, but will prevent us from dereferencing invalid
pointers.

For any later point in the work flow the scsi host object will be set and
thus nothing is changed then.

Link: https://lore.kernel.org/r/f51fe5f236a1e3d1ce53379c308777561bfe35e1.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Move p-t-p port allocation to after xport data

When doing the very first adapter recovery - initialization - for a FCP
device in a point-to-point topology we also allocate the port object
corresponding to the attached remote port, and trigger a port recovery for
it that will run after the adapter recovery finished.

Right now this happens right after we finished with the exchange config
data command, and uses the fibre channel host object corresponding to the
FCP device to determine whether a point-to-point topology is used.

When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this use of the fc_host object is not
possible anymore at that point in the work flow.

But the allocation and recovery trigger doesn't have notable side-effects
on the following exchange port data processing, so we can move those to
after xport data, and thus also to after the scsi host object allocation,
once we move it. Then the fc_host object can be used again, like it is now.

For any further adapter recoveries this doesn't change anything, because at
that point the port object already exists and recovery is triggered
elsewhere for existing port objects.

Link: https://lore.kernel.org/r/73e5d4ac21e2b37bf0c3ca8e530bc5a5c6e74f8f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Fence fc_host updates during link-down handling

When receiving a notification that a FCP device lost its local link we
usually update the fibre channel host object which represents that FCP
device to reflect that.

This notification/information can also surface when the FCP device is
running through adapter recovery (exchange config and exchange port data
return incomplete).

When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, and this happens during the very first
adapter recovery, these updates can not be done until after the scsi host
object is allocated.

Reorder the fc_host updates in zfcp_fsf_fc_host_link_down() so that they
only happen after a check of whether the scsi host object is already
allocated or not.

During the first adapter recovery this will cause the skip of these updates
if a link-down condition is detected, but we can repeat them after we
allocated the scsi host object, if necessary.

For any further link-down handling the only changes in the work flow are
the slightly reordered assignments in zfcp_fsf_fc_host_link_down().

Link: https://lore.kernel.org/r/f841f2cda61dcd7b8549910c44e1831927459edf.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Move fc_host updates during xport data handling into fenced function

When executing exchange port data for a FCP device for the first time, or
after an adapter recovery, we update several properties of the fibre
channel host object which represents that FCP device.

When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this is not possible for the former case.

Move all these update into separate, and fenced function that first checks
whether the scsi host object already exists or not, before making the
updates.

During the first ever exchange port data in the adapter life cycle this
will make the exchange port data handler skip over this update step, but we
can repeat it later, after we allocated the scsi host object.

For any further recovery of that adapter the work flow is only changed
slightly because then the scsi host object already exists and we don't free
it until we release the adapter completely at the end of its life cycle.

Link: https://lore.kernel.org/r/ae454c2dc6da0b02907c489af91d0b211d331825.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Move shost updates during xconfig data handling into fenced function

When executing exchange config data for a FCP device for the first time, or
after an adapter recovery, we update several properties of the scsi host or
fibre channel host object that represent that FCP device.

When moving the scsi host object allocation and registration - and thus
also the fibre channel host object allocation - to after the first exchange
config and exchange port data, this is not possible for the former case.

Move all these update into separate, and fenced function that first checks
whether the scsi host object already exists or not, before making the
updates.

During the first ever exchange config data in the adapter life cycle this
will make the exchange config data handler skip over this update step, but
we can repeat it later, after we allocated the scsi host object.

For any further recovery of that adapter the work flow is only changed
slightly because then the scsi host object already exists and we don't free
it until we release the adapter completely at the end of its life cycle.

Link: https://lore.kernel.org/r/5fc3f4d38d4334f7aa595497c6f7865fb1102e0f.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: zfcp: Move shost modification after QDIO (re-)open into fenced function

When establishing and activating the QDIO queue pair for a FCP device for
the first time, or after an adapter recovery, we publish some of its
characteristics to the scsi host object representing that FCP device.

When moving the scsi host object allocation and registration to after the
first exchange config and exchange port data, this is not possible for the
former case - QDIO open for the first time - because that happens before
exchange config and exchange port data.

Move the scsi host object update into a fenced function that checks whether
the object already exists or not. This way we can repeat that step later,
once we are past the allocation.

Once the first recovery succeeds we don't release the scsi host object
anymore, so further recoveries do work as before.

Link: https://lore.kernel.org/r/a214ebf508f71e3690113e3e90edab1cea0e24e3.1588956679.git.bblock@linux.ibm.com
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Remove unused including <linux/version.h>

Fix the following versioncheck warning:

drivers/scsi/mpt3sas/mpt3sas_debugfs.c:16:1: unused including <linux/version.h>

Link: https://lore.kernel.org/r/1588938573-57847-1-git-send-email-zou_wei@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Fix double free warnings

Fix following warning from Smatch static analyser:

drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->hpr_lookup' double freed

drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools()
warn: 'ioc->internal_lookup' double freed

Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.com
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Suganath Prabu S <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: megaraid_sas: Update driver version to 07.714.04.00-rc1

Link: https://lore.kernel.org/r/20200508085314.23461-1-chandrakanth.patil@broadcom.com
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: megaraid_sas: TM command refire leads to controller firmware crash

When TM command times out, driver invokes the controller reset. Post reset,
driver re-fires pended TM commands which leads to firmware crash.

Post controller reset, return pended TM commands back to OS.

Link: https://lore.kernel.org/r/20200508085242.23406-1-chandrakanth.patil@broadcom.com
Cc: stable@vger.kernel.org
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: megaraid_sas: Replace undefined MFI_BIG_ENDIAN macro with __BIG_ENDIAN_BITFIELD macro

MFI_BIG_ENDIAN macro used in drivers structure bitfield to check the CPU
big endianness is undefined which would break the code on big endian
machine. __BIG_ENDIAN_BITFIELD kernel macro should be used in places of
MFI_BIG_ENDIAN macro.

Link: https://lore.kernel.org/r/20200508085130.23339-1-chandrakanth.patil@broadcom.com
Fixes: a7faf81d7858 ("scsi: megaraid_sas: Set no_write_same only for Virtual Disk")
Cc: <stable@vger.kernel.org> # v5.6+
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: megaraid_sas: Remove IO buffer hole detection logic

As blk_queue_virt_boundary() API in slave_configure ensures that no IOs
will come with holes/gaps. Hence, code logic to detect the holes/gaps in IO
buffer is not required.

Link: https://lore.kernel.org/r/20200508083838.22778-3-chandrakanth.patil@broadcom.com
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: megaraid_sas: Limit device queue depth to controller queue depth

The driver currently assigns a pre-defined queue depth when the
firmware-provided device queue depth is greater than the controller queue
depth.

Use the controller queue depth if the reported target queue depth is too
large.

Link: https://lore.kernel.org/r/20200508083838.22778-2-chandrakanth.patil@broadcom.com
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Cleanup WriteBooster feature

Small cleanup as below items,

 1. Use ufshcd_is_wb_allowed() directly instead of ufshcd_wb_sup() since
    ufshcd_wb_sup() just returns the result of ufshcd_is_wb_allowed().

 2. In ufshcd_suspend(), "else if (!ufshcd_is_runtime_pm(pm_op)) can be
    simplified to "else" since both have the same meaning.

This patch does not change any functionality.

Link: https://lore.kernel.org/r/20200508080115.24233-9-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs-mediatek: Enable WriteBooster capability

Enable WriteBooster capability on MediaTek UFS platforms.

Link: https://lore.kernel.org/r/20200508080115.24233-8-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Add LU Dedicated buffer mode support for WriteBooster

According to UFS specification, there are two WriteBooster mode of
operations: "LU dedicated buffer" mode and "shared buffer" mode.  In the
"LU dedicated buffer" mode, the WriteBooster Buffer is dedicated to a
logical unit.

If the device supports the "LU dedicated buffer" mode, this mode is
configured by setting bWriteBoosterBufferType to 00h. The logical unit
WriteBooster Buffer size is configured by setting the
dLUNumWriteBoosterBufferAllocUnits field of the related Unit
Descriptor. Only a value greater than zero enables the WriteBooster feature
in the logical unit.

Modify ufshcd_wb_probe() as above description to support LU Dedicated
buffer mode.

Note that according to UFS 3.1 specification, the valid value of
bDeviceMaxWriteBoosterLUs parameter in Geometry Descriptor is 1, which
means at most one LUN can have WriteBooster buffer in "LU dedicated buffer
mode". Therefore this patch supports only one LUN with WriteBooster
enabled. All WriteBooster related sysfs nodes are specifically mapped to
the LUN with WriteBooster enabled in LU Dedicated buffer mode.

Link: https://lore.kernel.org/r/20200508080115.24233-7-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Add "index" in parameter list of ufshcd_query_flag()

For preparation of LU Dedicated buffer mode support on WriteBooster
feature, "index" parameter shall be added and allowed to be specified by
callers.

Link: https://lore.kernel.org/r/20200508080115.24233-6-stanley.chu@mediatek.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Can Guo <cang@codeaurora.org>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs-mediatek: Add fixup_dev_quirks vops

Add fixup_dev_quirk vops in MediaTek UFS platforms and provide an initial
vendor-specific device quirk table.

Link: https://lore.kernel.org/r/20200508080115.24233-5-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Export ufs_fixup_device_setup() function

Export ufs_fixup_device_setup() to allow vendors to re-use it for fixing
device quriks on specified UFS hosts.

Link: https://lore.kernel.org/r/20200508080115.24233-4-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Introduce fixup_dev_quirks vops

Some UFS deivces may have required device quirks or have non-standard
features which are enabled only on specified UFS hosts or for special
customers.

To not "pollute" common device quirk list, i.e. ufs_fixups table, for those
devices mentioned above, introduce "fixup_dev_quirks" vops to allow vendors
to fix or modify device quirks accordingly.

Link: https://lore.kernel.org/r/20200508080115.24233-3-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Enable WriteBooster on some pre-3.1 UFS devices

The WriteBooster feature can be supported by some pre-3.1 UFS devices by
upgrading firmware.

To enable WriteBooster feature in such devices, introduce a device quirk to
relax the entrance condition of ufshcd_wb_probe() to allow host driver to
check those devices' WriteBooster capability.

WriteBooster feature can be available if below all conditions are
satisfied,

 1. Host enables WriteBooster capability

 2. UFS 3.1 device or UFS pre-3.1 device with quirk
    UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled

 3. The device descriptor shall have DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP
    field

 4. WriteBooster support is specified in above field

Link: https://lore.kernel.org/r/20200508080115.24233-2-stanley.chu@mediatek.com
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Remove redundant initialization to variable rc

The variable rc is being initialized with a value that is never read and it
is being updated later with a new value.  The initialization is redundant
and can be removed.

Link: https://lore.kernel.org/r/20200507203111.64709-1-colin.king@canonical.com
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Addresses-Coverity: ("Unused value")

scsi: ufs: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these ones is a flexible array member[1][2], introduced in
C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by this
change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in which
the sizeof operator is being incorrectly/erroneously applied to zero-length
arrays and the result is zero. Such instances may be hiding some bugs. So,
this work (flexible-array member conversions) will also help to get
completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Link: https://lore.kernel.org/r/20200507192550.GA16683@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: libsas: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these ones is a flexible array member[1][2], introduced in
C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by this
change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in which
the sizeof operator is being incorrectly/erroneously applied to zero-length
arrays and the result is zero. Such instances may be hiding some bugs. So,
this work (flexible-array member conversions) will also help to get
completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Link: https://lore.kernel.org/r/20200507192147.GA16206@embeddedor
Reviewed-by: John Garry <john.garry@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qedi: Remove unused variable udev & uctrl

uctrl and udev are unused after commit 9632a6b4b747 ("scsi: qedi: Move LL2
producer index processing in BH.")

Remove them.

Link: https://lore.kernel.org/r/20200505121904.25702-1-xiexiuqi@huawei.com
Reviewed-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: bfa: Make bfad_iocmd_ioc_get_stats() static

Fix the following sparse warning:

drivers/scsi/bfa/bfad_bsg.c:140:1: warning: symbol
'bfad_iocmd_ioc_get_stats' was not declared. Should it be static?

Link: https://lore.kernel.org/r/20200505073807.40332-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: target: loopback: Fix READ with data and sensebytes

We use tcm_loop with tape emulations running on tcmu.

In case application reads a short tape block with a longer READ, or a long
tape block with a short READ, according to SCC spec data has to be
tranferred _and_ sensebytes with ILI set and information field containing
the residual count. Similar problem also exists when using fixed block
size in READ.

Up to now tcm_loop is not prepared to handle sensebytes if input data is
provided, as in tcm_loop_queue_data_in() it only sets SAM_STAT_GOOD and, if
necessary, the residual count.

To fix the bug, the same handling for sensebytes as present in
tcm_loop_queue_status() must be done in tcm_loop_queue_data_in() also.

After adding this handling, the two function now are nearly identical, so I
created a single function with two wrappers.

Link: https://lore.kernel.org/r/20200428182617.32726-1-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: aacraid: Use memdup_user() as a cleanup

Fix coccicheck warning which recommends to use memdup_user().

This patch fixes the following coccicheck warning:

drivers/scsi/aacraid/commctrl.c:516:15-22: WARNING opportunity for memdup_user

Link: https://lore.kernel.org/r/1587868964-75969-1-git-send-email-zou_wei@huawei.com
Fixes: 4645df1035b3 ("[PATCH] aacraid: swapped kmalloc args.")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Update lpfc version to 12.8.0.1

Update lpfc version to 12.8.0.1

Link: https://lore.kernel.org/r/20200501214310.91713-10-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Fix MDS Diagnostic Enablement definition

The MDS diagnostic enablement bit for the adapter interface is incorrect in
the driver header.

Correct the bit position for the SET_FEATURE MDS bit.

Link: https://lore.kernel.org/r/20200501214310.91713-9-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Fix noderef and address space warnings

Running make C=1 M=drivers/scsi/lpfc triggers sparse warnings

Correct the code generating the following errors:

 - Incompatible address space assignment without proper conversion.

 - Deference of usespace and per-cpu pointers.

Link: https://lore.kernel.org/r/20200501214310.91713-8-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Remove unnecessary lockdep_assert_held calls

In an audit of lockdep calls in the driver, there are multiple lockdep
checks in successive calling layers. E.g. a routine checks, and then calls
a lower routine that also checks, and so on. Calling sequences result in
many redundant checks.

Refine the code to remove lower-level lockdep checks.  Update comments on
the lock, correcting a few places where lock object in comment was
incorrect.

Link: https://lore.kernel.org/r/20200501214310.91713-7-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Change default queue allocation for reduced memory consumption

By default, the driver attempts to allocate a hdwq per logical cpu in order
to provide good cpu affinity. Some systems have extremely high cpu counts
and this can significantly raise memory consumption.

In testing on x86 platforms (non-AMD) it is found that sharing of a hdwq by
a physical cpu and its HT cpu can occur with little performance
degredation. By sharing, the hdwq count can be halved, significantly
reducing the memory overhead.

Change the default behavior of the driver on non-AMD x86 platforms to
share a hdwq by the cpu and its HT cpu.

Link: https://lore.kernel.org/r/20200501214310.91713-6-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Fix negation of else clause in lpfc_prep_node_fc4type

Implementation of a previous patch added a condition to an if check that
always end up with the if test being true. Execution of the else clause was
inadvertently negated.  The additional condition check was incorrect and
unnecessary after the other modifications had been done in that patch.

Remove the check from the if series.

Link: https://lore.kernel.org/r/20200501214310.91713-5-jsmart2021@gmail.com
Fixes: b95b21193c85 ("scsi: lpfc: Fix loss of remote port after devloss due to lack of RPIs")
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Remove re-binding of nvme rport during registration

The lldd rebinds the ndlp with rport during a nvme rport registration (via
nvme_fc_register_remoteport). If rport & ndlp pointers are same as the
previous one, the lldd will re-use the ndlp and rport association without
re-initialization. This assumption is incorrect. The lldd should be
ignorant of whether the returned rport pointer is new or not, and should
always assume it is new.

Remove the re-binding code, always assumes that rport pointer received from
transport is a new pointer.

Link: https://lore.kernel.org/r/20200501214310.91713-4-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: lpfc: Maintain atomic consistency of queue_claimed flag

A previous change introduced the atomic use of queue_claimed flag for eq's
and cq's.  The code works fine, but the clearing of the queue_claimed flag
is not atomic.

Change queue_claimed = 0 into xchg(&queue_claimed, 0) to be consistent for
change under atomicity.

Link: https://lore.kernel.org/r/20200501214310.91713-3-jsmart2021@gmail.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: target: tcmu: Make pgr_support and alua_support attributes writable

Currently in tcmu reservation commands are handled by core's pr
implementation (default) or completely rejected (emulate_pr set to 0). We
additionally want to be able to do full reservation handling in
userspace. Therefore we need a way to set TRANSPORT_FLAG_PASSTHROUGH_PGR.

The inverted flag is displayed by attribute pgr_support.  Since we moved
the flag from transport/backend to se_device in the previous commit, we now
can make it changeable per device by allowing to write the attribute.  The
new field transport_flags_changeable in transport/backend is used to reject
writing if not allowed for a backend.

Regarding ALUA we also want to be able to passthrough commands to userspace
in tcmu. Therefore we need TRANSPORT_FLAG_PASSTHROUGH_ALUA to be
changeable, because by setting it we can switch off all ALUA checks in
core. So we also set TRANSPORT_FLAG_PASSTHROUGH_ALUA in tcmu's
transport_flags_changeable.

Of course, ALUA and reservation handling in userspace will work only, if
session/nexus information is sent to userspace along with every
command. This will be object of a patch series announced by Mike Christie.

Link: https://lore.kernel.org/r/20200427150823.15350-5-bstroesser@ts.fujitsu.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: target: Make transport_flags per device

pgr_support and alua_support device attributes show the inverted value of
the transport_flags:

 * TRANSPORT_FLAG_PASSTHROUGH_PGR
 * TRANSPORT_FLAG_PASSTHROUGH_ALUA

These attributes are per device, while the flags are per backend. Rename
the transport_flags in backend/transport to transport_flags_default and use
this value to initialize the new transport_flags field in the se_device
structure.

Now data and attribute both are per se_device.

Link: https://lore.kernel.org/r/20200427150823.15350-4-bstroesser@ts.fujitsu.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: target: tcmu: Add attributes enforce_pr_isids and force_pr_aptpl

tcmu has not set TRANSPORT_FLAG_PASSTHROUGH_PGR. Therefore the in-core pr
emulation is active by default, but there are some attributes for
configuration missing. Add them.

Link: https://lore.kernel.org/r/20200427150823.15350-3-bstroesser@ts.fujitsu.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: target: Add missing emulate_pr attribute to passthrough backends

In commit b49d6f788530 ("scsi: target: add emulate_pr backstore attr to
toggle PR support") the new attribute emulate_pr was added.

passthrough_parse_cdb() uses the attribute's value to distinguish whether
reservation commands should be rejected or not.  But the new attribute was
not added to passthrough_attrib_attrs, so in pscsi and tcmu - the users of
passthrough_parse_cdb() - the attribute is not available to change parser's
behavior.

Link: https://lore.kernel.org/r/20200427150823.15350-2-bstroesser@ts.fujitsu.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Disable DIF when prot_mask set to zero

By default DIF Type 1, DIF Type 2 & DIF Type 3 will be enabled.  Also,
users can enable either DIF Type 1 or DIF Type 2 or DIF Type 3 or in any
combination using the prot_mask module parameter.

However, when the user provides a prot_mask module parameter value of zero,
then the driver is not disabling the DIF. Instead it enables all three
types.

Modify the driver to disable the DIF support if the user provides a
prot_mask module parameter value of zero.

Link: https://lore.kernel.org/r/1588065902-2726-1-git-send-email-sreekanth.reddy@broadcom.com
Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Update maintainers

Updated maintainers list for MPT DRIVERS

Link: https://lore.kernel.org/r/1588056428-29369-1-git-send-email-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Capture IOC data for debugging purposes

Information needed to debug driver problems and firmware faults is stored
in the IOC’s MPT3SAS_ADAPTER data structure. Parameters such as IOCFacts,
IOC flags (related to sge, MSI-X, error recovery etc.), performance mode
type, TMs, internal commands reply status, etc. are present.

For debugging purposes, it is therefore helpful to be able to capture this
information so that the fault can be analyzed. Export the MPT3SAS_ADAPTER
data structure in debugfs. The data is available in:

 /sys/kernel/debug/mpt3sas/scsi_hostX/ioc_dump

Link: https://lore.kernel.org/r/1588056322-29227-1-git-send-email-suganath-prabu.subramani@broadcom.com
Signed-off-by: Suganath Prabu <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Use true, false for ioc->use_32bit_dma

Fix the following coccicheck warning:

drivers/scsi/mpt3sas/mpt3sas_base.c:7202:1-19: WARNING: Assignment of
0/1 to bool variable

Link: https://lore.kernel.org/r/20200430121738.15151-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: vmw_pvscsi: Use true, false for adapter->use_msg

Fix the following coccicheck warning:

drivers/scsi/vmw_pvscsi.c:911:2-18: WARNING: Assignment of 0/1 to bool
variable

Link: https://lore.kernel.org/r/20200430121729.15064-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: fnic: Use true, false for fnic->internal_reset_inprogress

Fix the following coccicheck warning:

drivers/scsi/fnic/fnic_scsi.c:2627:5-36: WARNING: Comparison of 0/1 to
bool variable

Link: https://lore.kernel.org/r/20200430121718.14970-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qedi: Remove comparison of 0/1 to bool variable

Fix the following coccicheck warning:

drivers/scsi/qedi/qedi_main.c:1309:5-25: WARNING: Comparison of 0/1 to
bool variable
drivers/scsi/qedi/qedi_main.c:1315:5-25: WARNING: Comparison of 0/1 to
bool variable

Link: https://lore.kernel.org/r/20200430121706.14879-1-yanaijie@huawei.com
Acked-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: aacraid: Make some symbols static

Fix the following sparse warnings:

drivers/scsi/aacraid/linit.c:867:6: warning:
symbol 'aac_tmf_callback' was not declared. Should it be static?
drivers/scsi/aacraid/linit.c:1081:5: warning:
symbol 'aac_eh_host_reset' was not declared. Should it be static?
drivers/scsi/aacraid/commsup.c:2354:5: warning:
symbol 'aac_send_safw_hostttime' was not declared. Should it be static?
drivers/scsi/aacraid/commsup.c:2383:5: warning:
symbol 'aac_send_hosttime' was not declared. Should it be static?

Link: https://lore.kernel.org/r/1588240932-69020-1-git-send-email-zou_wei@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Make qlafx00_process_aen() return void

No other functions use the return value of qlafx00_process_aen() and the
return value is always 0 now. Make it return void. This fixes the following
coccicheck warning:

drivers/scsi/qla2xxx/qla_mr.c:1716:5-9: Unneeded variable: "rval".
Return "0" on line 1768

Link: https://lore.kernel.org/r/20200506061757.19536-1-yanaijie@huawei.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Use true, false for ha->fw_dumped

Fix the following coccicheck warning:

drivers/scsi/qla2xxx/qla_tmpl.c:1120:2-20: WARNING: Assignment of 0/1 to
bool variable

Link: https://lore.kernel.org/r/20200430121800.15323-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Use true, false for need_mpi_reset

Fix the following coccicheck warning:

drivers/scsi/qla2xxx/qla_tmpl.c:1031:6-20: WARNING: Assignment of 0/1 to
bool variable
drivers/scsi/qla2xxx/qla_tmpl.c:1062:3-17: WARNING: Assignment of 0/1 to
bool variable

Link: https://lore.kernel.org/r/20200430121751.15232-1-yanaijie@huawei.com
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Make qla_set_ini_mode() return void

The return value is not used by the caller and the local variable 'rc' is
not needed. Make qla_set_ini_mode() return void and remove 'rc'.  This also
fixes the following coccicheck warning:

drivers/scsi/qla2xxx/qla_attr.c:1906:5-7: Unneeded variable: "rc".
Return "0" on line 2180

Link: https://lore.kernel.org/r/20200429140952.8240-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Fix issue with adapter's stopping state

The goal of the following command sequence is to restart the adapter.
However, the tgt_stop flag remains set, indicating that the adapter is
still in stopping state even after re-enabling it.

echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging
modprobe target_core_mod
modprobe tcm_qla2xxx
mkdir /sys/kernel/config/target/qla2xxx
mkdir /sys/kernel/config/target/qla2xxx/<port-name>
mkdir /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 0 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable

kernel: PID 1396:qla_target.c:1555 qlt_stop_phase1(): tgt_stop 0x0, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-e803:1: PID 1396:qla_target.c:1567: Stopping target for host 1(c0000000033557e8)
kernel: PID 1396:qla_target.c:1579 qlt_stop_phase1(): tgt_stop 0x1, tgt_stopped 0x0
kernel: PID 1396:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-e801:1: PID 1396:qla_target.c:1316: Scheduling sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7
<skipped>
kernel: qla2xxx [0001:00:02.0]-290a:1: PID 340:qla_target.c:1187: qlt_unreg_sess sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7
<skipped>
kernel: qla2xxx [0001:00:02.0]-f801:1: PID 340:qla_target.c:1145: Unregistration of sess c00000002d5cd800 21:00:00:24:ff:7f:35:c7 finished fcp_cnt 0
kernel: PID 340:qla_target.c:1155 qlt_free_session_done(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled.
<skipped>
kernel: qla2xxx [0001:00:02.0]-28f1:1: PID 346:qla_os.c:3956: Mark all dev lost
kernel: PID 346:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end.
<skipped>
kernel: PID 1396:qla_target.c:6812 qlt_enable_vha(): tgt_stop 0x1, tgt_stopped 0x0
<skipped>
kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled.
<skipped>
kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end.

qlt_handle_cmd_for_atio() rejects the request to send commands because the
adapter is in the stopping state:

kernel: PID 0:qla_target.c:4442 qlt_handle_cmd_for_atio(): tgt_stop 0x1, tgt_stopped 0x0
kernel: qla2xxx [0001:00:02.0]-3861:1: PID 0:qla_target.c:4447: New command while device c000000005314600 is shutting down
kernel: qla2xxx [0001:00:02.0]-e85f:1: PID 0:qla_target.c:5728: qla_target: Unable to send command to target

This patch calls qla_stop_phase2() in addition to qlt_stop_phase1() in
tcm_qla2xxx_tpg_enable_store() and tcm_qla2xxx_npiv_tpg_enable_store(). The
qlt_stop_phase1() marks adapter as stopping (tgt_stop == 0x1, tgt_stopped
== 0x0) but qlt_stop_phase2() marks adapter as stopped (tgt_stop == 0x0,
tgt_stopped == 0x1).

Link: https://lore.kernel.org/r/52be1e8a3537f6c5407eae3edd4c8e08a9545ea5.camel@yadro.com
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Viacheslav Dubeyko <v.dubeiko@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Fix failure message in qlt_disable_vha()

The following sequence of commands result in an incorrect failure message
being printed:

echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging
modprobe target_core_mod
modprobe tcm_qla2xxx
mkdir /sys/kernel/config/target/qla2xxx
mkdir /sys/kernel/config/target/qla2xxx/<port-name>
mkdir /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 0 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable

qla2xxx [0001:00:02.0]-e881:1: qla2x00_wait_for_hba_online() failed

The reason of this message is the QLA_FUNCTION_FAILED code that
qla2x00_wait_for_hba_online() returns. However, qlt_disable_vha() expects
that adapter is offlined and QLA_FUNCTION_FAILED informs about the offline
state of the adapter.

The qla2x00_abort_isp() function finishes the execution at the point of
checking the adapter's mode (for example, qla_tgt_mode_enabled()) because
of the qlt_disable_vha() calls qlt_clear_mode() method. It means that
qla2x00_abort_isp() keeps vha->flags.online is equal to zero. Finally,
qla2x00_wait_for_hba_online() checks the state of this flag and returns
QLA_FUNCTION_FAILED error code.

This patch changes the failure message which informs about adapter's
offline state.

Link: https://lore.kernel.org/r/3cd0bbf3599c53b0c2a7184582d705d8b8052c8b.camel@yadro.com
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Viacheslav Dubeyko <v.dubeiko@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: Fix warning after FC target reset

Currently, FC target reset finishes with the warning message:

[84010.596893] ------------[ cut here ]------------
[84010.596917] WARNING: CPU: 238 PID: 279973 at ../drivers/scsi/qla2xxx/qla_target.c:6644 qlt_enable_vha+0x1d0/0x260 [qla2xxx]
[84010.596918] Modules linked in: vrf af_packet 8021q garp mrp stp llc netlink_diag target_tatlin_tblock(OEX) dm_ec(OEX) ttln_rdma(OEX) dm_frontend(OEX) nvme_rdma nvmet tcm_qla2xxx iscsi_target_mod target_core_mod at24 nvmem_core pnv_php ipmi_watchdog ipmi_ssif vmx_crypto gf128mul crct10dif_vpmsum qla2xxx rpcrdma nvme_fc powernv_flash(X) nvme_fabrics uio_pdrv_genirq mtd rtc_opal(X) ibmpowernv(X) opal_prd(X) uio scsi_transport_fc i2c_opal(X) ses enclosure ipmi_poweroff ast i2c_algo_bit ttm bmc_mcu(OEX) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks agpgart nfsd auth_rpcgss nfs_acl ipmi_powernv(X) lockd ipmi_devintf ipmi_msghandler grace dummy ext4 crc16 jbd2 mbcache sd_mod rdma_ucm ib_iser rdma_cm ib_umad iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm
[84010.596975]  configfs mlx5_ib ib_uverbs ib_core mlx5_core crc32c_vpmsum xhci_pci xhci_hcd mpt3sas(OEX) tg3 usbcore mlxfw tls raid_class libphy scsi_transport_sas devlink ptp pps_core nvme nvme_core sunrpc dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
[84010.597001] Supported: Yes, External
[84010.597004] CPU: 238 PID: 279973 Comm: bash Tainted: G           OE      4.12.14-197.29-default #1 SLE15-SP1
[84010.597006] task: c000000a104c0000 task.stack: c000000b52188000
[84010.597007] NIP: d00000001ffd7f78 LR: d00000001ffd7f6c CTR: c0000000001676c0
[84010.597008] REGS: c000000b5218b910 TRAP: 0700   Tainted: G           OE       (4.12.14-197.29-default)
[84010.597008] MSR: 900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>
[84010.597015]   CR: 48242424  XER: 00000000
[84010.597016] CFAR: d00000001ff45d08 SOFTE: 1
               GPR00: d00000001ffd7f6c c000000b5218bb90 d00000002001b228 0000000000000102
               GPR04: 0000000000000001 0000000000000001 00013d91ed0a5e2d 0000000000000000
               GPR08: c000000007793300 0000000000000000 0000000000000000 c000000a086e7818
               GPR12: 0000000000002200 c000000007793300 0000000000000000 000000012bc937c0
               GPR16: 000000012bbf7ed0 0000000000000000 000000012bc3dd10 0000000000000000
               GPR20: 000000012bc4db28 0000010036442810 000000012bc97828 000000012bc96c70
               GPR24: 00000100365b1550 0000000000000000 00000100363f3d80 c000000be20d3080
               GPR28: c000000bda7eae00 c000000be20db7e8 c000000be20d3778 c000000be20db7e8
[84010.597042] NIP [d00000001ffd7f78] qlt_enable_vha+0x1d0/0x260 [qla2xxx]
[84010.597051] LR [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx]
[84010.597051] Call Trace:
[84010.597061] [c000000b5218bb90] [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] (unreliable)
[84010.597064] [c000000b5218bc20] [d000000009820b6c] tcm_qla2xxx_tpg_enable_store+0xc4/0x130 [tcm_qla2xxx]
[84010.597067] [c000000b5218bcb0] [d0000000185d0e68] configfs_write_file+0xd0/0x190 [configfs]
[84010.597072] [c000000b5218bd00] [c0000000003d0edc] __vfs_write+0x3c/0x1e0
[84010.597074] [c000000b5218bd90] [c0000000003d2ea8] vfs_write+0xd8/0x220
[84010.597076] [c000000b5218bde0] [c0000000003d4ddc] SyS_write+0x6c/0x110
[84010.597079] [c000000b5218be30] [c00000000000b188] system_call+0x3c/0x130
[84010.597080] Instruction dump:
[84010.597082] 7d0050a8 7d084b78 7d0051ad 40c2fff4 7fa3eb78 4bf73965 60000000 7fa3eb78
[84010.597086] 4bf6dcd9 60000000 2fa30000 419eff40 <0fe00000> 4bffff38 e95f0058 a12a0180
[84010.597090] ---[ end trace e32abaf6e6fee826 ]---

To reproduce:

echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging
modprobe target_core_mod
modprobe tcm_qla2xxx
mkdir /sys/kernel/config/target/qla2xxx
mkdir /sys/kernel/config/target/qla2xxx/<port-name>
mkdir /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 0 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable
echo 1 > /sys/kernel/config/target/qla2xxx/<port-name>/tpgt_1/enable

SYSTEM START
kernel: pid 327:drivers/scsi/qla2xxx/qla_init.c:2174 qla2x00_initialize_adapter(): vha->flags.online 0x0
<...>
kernel: pid 327:drivers/scsi/qla2xxx/qla_os.c:3444 qla2x00_probe_one(): vha->flags.online 0x1

echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable
kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0
<...>
kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6998 qla2x00_restart_isp(): vha->flags.online 0x0

echo 0 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable
kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0
<...>
kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0

echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable
kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0
kernel: -----------[ cut here ]-----------
kernel: WARNING: CPU: 1 PID: 1404 at drivers/scsi/qla2xxx/qla_target.c:6654 qlt_enable_vha+0x1e0/0x280 [qla2xxx]

The issue happens because no real ISP reset is executed.  The
qla2x00_abort_isp(scsi_qla_host_t *vha) function expects that
vha->flags.online will be not zero for ISP reset procedure.  This patch
sets vha->flags.online to 1 before calling ->abort_isp() for starting the
ISP reset.

Link: https://lore.kernel.org/r/1d7b21bf9f7676643239eb3d60eaca7cfa505cf0.camel@yadro.com
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Viacheslav Dubeyko <v.dubeiko@yadro.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: core: Remove 'list' entry from struct scsi_cmnd

Leftover from cmd_list removal.

Link: https://lore.kernel.org/r/20200507062642.100612-1-hare@suse.de
Fixes: c5a9707672fe ("scsi: core: Remove cmd_list functionality")
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Disallow zone sizes that are not powers of 2

Allowing a non-power-of-2 zone size forces the use of direct division
operations of 64-bit sector values to obtain a zone number or number of
zones. Doing so without using do_div() leads to compilation errors on
32-bit architectures.

Devices with a zone size that is not a power of 2 do not exist today so
allowing their emulation is of limited interest as the sd driver will not
support them anyway. To fix this compilation error, instead of using
do_div() for sector values divisions, simply disallow zone size values that
are not a power of 2.

[mkp: commit desc]

Link: https://lore.kernel.org/r/20200507023526.221574-1-damien.lemoal@wdc.com
Fixes: 98e0a689868c ("scsi: scsi_debug: Add zone_size_mb module parameter")
Fixes: f0d1cf9378bd ("scsi: scsi_debug: Add ZBC zone commands")
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Implement ZBC host-aware emulation

Implement ZBC host-aware device model emulation. The main changes from the
host-managed emulation are the device type (TYPE_DISK is used), relaxation
of access checks for read and write operations and different handling of a
sequential write preferred zone write pointer as mandated by the ZBC r05
specifications.

To facilitate the implementation and avoid a lot of "if" statement, the
zmodel field is added to the device information and the z_type field to the
zone state data structure.

Link: https://lore.kernel.org/r/20200422104221.378203-8-damien.lemoal@wdc.com
Tested-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add zone_size_mb module parameter

Add the zone_size_mb module parameters to control the zone size of a ZBC
device. If the zone size specified is not a divisor of the device capacity,
the last zone of the device will be created as a smaller "runt" zone. This
parameter is ignored for device types other than 0x14 (zbc=2 case).

Note: for testing purposes, zone sizes that are not a power of 2 are
accepted but will result in the drive being rejected by the sd driver.

Link: https://lore.kernel.org/r/20200422104221.378203-7-damien.lemoal@wdc.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add zone_nr_conv module parameter

Allow controlling the number of conventional zones of a ZBC device with the
new zone_nr_conv module parameter. The default value is 1 and the specified
value must be less than the total number of zones of the device. This
parameter is ignored for device types other than 0x14 (zbc=2 case).

Link: https://lore.kernel.org/r/20200422104221.378203-6-damien.lemoal@wdc.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add zone_max_open module parameter

Add the zone_max_open module parameters to control the maximum number of
open zones of a ZBC device. This parameter is ignored for device types
other than 0x14 (zbc=2 case).

Link: https://lore.kernel.org/r/20200422104221.378203-5-damien.lemoal@wdc.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add ZBC module parameter

Add the zbc module parameter to take either:
    0: none         (probably a conventional disk)
    1: host-aware
    2: host-managed

These values are chosen to match 'enum blk_zoned_model' found in
include/linux/blkdev.h . Instead of "none", "no" or "0" can be given.
Instead of "host-aware", "aware or "1" can be given. Instead of
"host-managed", "managed" or "2" can be given.

Note: the zbc parameter can only be given at driver/module load time; it
cannot be changed via sysfs thereafter.

At this time there is no ZBC "host-aware" implementation so that string (or
the value '1') results in a modprobe error.

Link: https://lore.kernel.org/r/20200422104221.378203-4-damien.lemoal@wdc.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add ZBC zone commands

Add support for the 5 ZBC commands and enough functionality to emulate a
host-managed device with one conventional zone and a set of sequential
write-required zones up to the disk capacity.

Link: https://lore.kernel.org/r/20200422104221.378203-3-damien.lemoal@wdc.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add ZBC mode and VPD pages

The ZBC standard "piggy-backs" on many, but not all, of the facilities in
SBC. Add those ZBC mode pages (plus mode parameter block descriptors
(e.g. "WP")) and VPD pages in common with SBC. Add ZBC specific VPD page
for the host-managed ZBC device type (ptype=0x14).

Link: https://lore.kernel.org/r/20200422104221.378203-2-damien.lemoal@wdc.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Bump to version 1.89

The scsi_debug driver version is visible in:

   /sys/modules/scsi_debug/version

and can thus be used by user space programs to alter the features they try
to use. Since the per_host_store and zbc/zone options are significant
additions, bump the version number to 1.89 .

Link: https://lore.kernel.org/r/20200421151424.32668-9-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Re-arrange parameters alphabetically

This module has a lot of parameters and when searching for one, the author
prefers them in alphabetical order. This can lead to somewhat illogical
ordering (e.g. inq_product before inq_vendor). However it is not clear what
another sensible total logical ordering would be.

Link: https://lore.kernel.org/r/20200421151424.32668-8-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Implement PRE-FETCH commands

Many disks implement the SCSI PRE-FETCH commands. One use case might be a
disk-to-disk compare, say between disks A and B. Then this sequence of
commands might be used: PRE-FETCH(from B, IMMED), READ(from A), VERIFY
(BYTCHK=1 on B with data returned from READ).  The PRE-FETCH (which returns
quickly due to the IMMED) fetches the data from the media into B's cache
which should speed the trailing VERIFY command. The next chunk of the
compare might be done in parallel, with A and B reversed.

The implementation tries to bring the specified range in main memory into
the cache(s) associated with this machine's CPU(s) using the
prefetch_range() function.

Link: https://lore.kernel.org/r/20200421151424.32668-7-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Improve command duration calculation

Previously the code did the work implied by the given SCSI command and
after that it waited for a timer based on the user specified command
duration to be exhausted before informing the mid-level that the command
was complete. For short command durations, the time to complete the work
implied by the SCSI command could be significant compared to the user
specified command duration.

For example a WRITE of 128 blocks (say 512 bytes each) on a machine that
can copy from main memory to main memory at a rate of 10 GB/sec will take
around 6.4 microseconds to do that copy.  If the user specified a command
duration of 5 microseconds (ndelay=5000), should the driver do a further
delay of 5 microseconds after the copy or return immediately because 6.4 >
5 ?

The action prior to this patch was to always do the timer based
delay. After this patch, for ndelay values less than 1 millisecond, this
driver will complete the command immediately.  And in the case where the
user specified delay was 7 microseconds, a timer delay of 600 nanoseconds
will be set ((7 - 6.4) * 1000).

Link: https://lore.kernel.org/r/20200421151424.32668-6-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Weaken rwlock around ramdisk access

The design of this driver is to do any ramdisk access on the same thread
that invoked the queuecommand() call. That is assumed to be user space
context. The command duration is implemented by setting the delay with a
high resolution timer. The hr timer's callback may well be in interrupt
context, but it doesn't touch the ramdisk. So try removing the
_irqsave()/_irqrestore() portion on the read-write lock that protects
ramdisk access.

Link: https://lore.kernel.org/r/20200421151424.32668-5-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Implement VERIFY(10), add VERIFY(16)

With the addition of the per_host_store option, the ability to check
whether two different ramdisk images are the same or not becomes
practical. Prior to this patch VERIFY(10) always returned true (i.e.  the
SCSI GOOD status) without checking. This option adds support for BYTCHK
equal to 0, 1 and 3. If the comparison fails, then a sense key of
MISCOMPARE is returned as per the T10 standards. Also add support for the
VERIFY(16) command.

Link: https://lore.kernel.org/r/20200421151424.32668-4-dgilbert@interlog.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Add per_host_store option

The scsi_debug driver has always been restricted to using one ramdisk image
(or none) for its storage. This means that thousands of scsi_debug devices
can be created without exhausting the host machine's RAM. The downside is
that all scsi_debug devices share the same ramdisk image. This option
changes the way a following write to the add_host parameter (or an add_host
in the module/driver invocation) operates.  For each new host that is
created while per_host_store is true, a new store (of dev-size_mb MiB) is
created and associated with all the LUs that belong to that new host. The
user (who will need root permissions) needs to take care not to exhaust all
the machine's available RAM.

One reason for doing this is to check that (partial) disk to disk copies
based on scsi_debug devices have actually copied accurately. To test this
the add_host=<n> parameter where <n> is 2 or greater can be used when the
scsi_debug module is loaded. Let us assume that /dev/sdb and /dev/sg1 are
the same scsi_debug device, while /dev/sdc and /dev/sg2 are the same
scsi_debug device. With per_host_store=1 add_host=2 they will have
different ramdisk images. Then the following pseudocode could be executed
to check if the sgh_dd copy worked:

    dd if=/dev/urandom of=/dev/sdb
    sgh_dd if=/dev/sg1 of=/dev/sg2 [plus option(s) to test]
    cmp /dev/sdb /dev/sdc

If the cmp fails then the copy has failed (or some other mechanism wrote to
/dev/sdb or /dev/sdc in the interim).

[mkp: use kstrtobool()]

Link: https://lore.kernel.org/r/20200421151424.32668-3-dgilbert@interlog.com
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: scsi_debug: Randomize command completion time

Add a new command line option (e.g. random=1) and sysfs attribute that
causes subsequent command completion times to be between the current
command delay setting and 0. A uniformly distributed 32 bit, kernel
provided integer is used for this purpose.

Since the existing 'delay' whose units are jiffies (typically milliseconds)
and 'ndelay' (units: nanoseconds) options (and sysfs attributes) span a
range greater than 32 bits, some scaling is required.

The purpose of this patch is to widen the range of testing cases that are
visited in long running tests. Put simply: rarely struct race conditions
are more likely to be found when this facility is used.

The default is the previous case in which all command completions were
roughly equal to (if not, slightly longer) than the value given by the
'delay' or 'ndelay' settings (or their defaults).  This option's default is
equivalent to setting 'random=0' .

[mkp: use kstrtobool()]

Link: https://lore.kernel.org/r/20200421151424.32668-2-dgilbert@interlog.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: dpt_i2o: Remove always false 'chan < 0' statement

The channel index is represented by an unsigned variable 'u32 chan'. We
don't need to check whether it is less than zero, the 'chan < 0' statement
is always false. Remove it.

Link: https://lore.kernel.org/r/1588162218-61757-1-git-send-email-wangxiongfeng2@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qedi: Check for buffer overflow in qedi_set_path()

Smatch complains that the "path_data->handle" variable is user controlled.
It comes from iscsi_set_path() so that seems possible.  It's harmless to
add a limit check.

The qedi->ep_tbl[] array has qedi->max_active_conns elements (which is
always ISCSI_MAX_SESS_PER_HBA (4096) elements).  The array is allocated in
the qedi_cm_alloc_mem() function.

Link: https://lore.kernel.org/r/20200428131939.GA696531@mwanda
Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.")
Acked-by: Manish Rangankar <mrangankar@marvell.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla2xxx: make 1-bit bit-fields unsigned int

The bitfields mpi_fw_dump_reading and mpi_fw_dumped are currently signed
which is not recommended as the representation is an implementation defined
behaviour.  Fix this by making the bit-fields unsigned ints.

Link: https://lore.kernel.org/r/20200428102013.1040598-1-colin.king@canonical.com
Fixes: cbb01c2f2f63 ("scsi: qla2xxx: Fix MPI failure AEN (8200) handling")
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: core: free sgtables in case command setup fails

In case scsi_setup_fs_cmnd() fails we're not freeing the sgtables allocated
by scsi_init_io(), thus we leak the allocated memory.

Free the sgtables allocated by scsi_init_io() in case scsi_setup_fs_cmnd()
fails.

Technically scsi_setup_scsi_cmnd() does not suffer from this problem as it
can only fail if scsi_init_io() fails, so it does not have sgtables
allocated. But to maintain symmetry and as a measure of defensive
programming, free the sgtables on scsi_setup_scsi_cmnd() failure as well.
scsi_mq_free_sgtables() has safeguards against double-freeing of memory so
this is safe to do.

While we're at it, rename scsi_mq_free_sgtables() to scsi_free_sgtables().

Link: https://bugzilla.kernel.org/show_bug.cgi?id=205595
Link: https://lore.kernel.org/r/20200428104605.8143-2-johannes.thumshirn@wdc.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Daniel Wagner <dwagner@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: core: doc: Change function comments to kernel-doc style

Despite of functions being documented, they are not in the kernel-doc
specification, and could not be included in kernel documentation. Change
the style of functions comments to be compliant to the kernel-doc style.
When the function comments are outdated, update then.

[mkp: a few edits]

Link: https://lore.kernel.org/r/20200419050148.33371-1-andrealmeid@collabora.com
Signed-off-by: André Almeida <andrealmeid@collabora.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs-qcom: Configure write booster type

Enable WriteBooster for Qualcomm platform.

Link: https://lore.kernel.org/r/cd4cf745ea0b3a59c2075036e17316b97494fe65.1587591527.git.asutoshd@codeaurora.org
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: sysfs: Add sysfs entries for write booster

Adds unit, device, geometry descriptor sysfs entries.  Adds flags sysfs
entries for write booster.

Link: https://lore.kernel.org/r/98987ef17844292bd42c57613990a3a26c6de2b8.1587591527.git.asutoshd@codeaurora.org
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Add write booster feature support

The write performance of TLC NAND is considerably lower than SLC NAND.
Using SLC NAND as a WriteBooster Buffer enables the write request to be
processed with lower latency and improves the overall write performance.

Adds support for shared-buffer mode WriteBooster.

WriteBooster enable: SW enables it when clocks are scaled up, thus it's
enabled only in high load conditions.

WriteBooster disable: SW will disable the feature, when clocks are scaled
down. Thus writes would go as normal writes.

To keep the endurance of the WriteBooster Buffer at a maximum, this
load-based toggling is adopted.

Link: https://lore.kernel.org/r/2871444d9083b0e9323ef6d8ff1b544b7784adc9.1587591527.git.asutoshd@codeaurora.org
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ufs: Use true for bool variables in ufshcd_complete_dev_init()

Fix the following coccicheck warning:

drivers/scsi/ufs/ufshcd.c:4140:6-14: WARNING: Assignment of 0/1 to bool
variable.

Link: https://lore.kernel.org/r/20200426094305.24083-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: sr: Use {get,put}_unaligned_be*() instead of open-coding these functions

This patch makes the sr code slightly easier to read.

Link: https://lore.kernel.org/r/20200427014844.12109-1-bvanassche@acm.org
Cc: Merlijn Wajer <merlijn@archive.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: aacraid: Fix error handling paths in aac_probe_one()

If 'scsi_host_alloc()' or 'kcalloc()' fail, 'error' is known to be 0. Set
it explicitly to -ENOMEM before branching to the error handling path.

While at it, remove 2 useless assignments to 'error'. These values are
overwridden a few lines later.

Link: https://lore.kernel.org/r/20200412094039.8822-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: sgiwd93: Remove unneeded semicolon in sgiwd93.c

Fix the following coccicheck warning:

drivers/scsi/sgiwd93.c:190:2-3: Unneeded semicolon

Link: https://lore.kernel.org/r/20200421034029.28030-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: qla4xxx: Remove unneeded semicolon in ql4_os.c

Fix the following coccicheck warning:

drivers/scsi/qla4xxx/ql4_os.c:969:3-4: Unneeded semicolon

Link: https://lore.kernel.org/r/20200421034038.28113-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: isci: Use true, false for bool variables

Fix the following coccicheck warning:

drivers/scsi/isci/isci.h:515:1-12: WARNING: Assignment of 0/1 to bool
variable
drivers/scsi/isci/isci.h:503:1-12: WARNING: Assignment of 0/1 to bool
variable
drivers/scsi/isci/isci.h:509:1-12: WARNING: Assignment of 0/1 to bool
variable

Link: https://lore.kernel.org/r/20200421034050.28193-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: bnx2fc: Remove unneeded semicolon in bnx2fc_fcoe.c

Fix the following coccicheck warning:

drivers/scsi/bnx2fc/bnx2fc_fcoe.c:948:4-5: Unneeded semicolon
drivers/scsi/bnx2fc/bnx2fc_fcoe.c:968:4-5: Unneeded semicolon

Link: https://lore.kernel.org/r/20200421034019.27949-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: bfa: Remove unneeded semicolon in bfa_fcs_rport.c

Fix the following coccicheck warning:

drivers/scsi/bfa/bfa_fcs_rport.c:2452:2-3: Unneeded semicolon
drivers/scsi/bfa/bfa_fcs_rport.c:1578:3-4: Unneeded semicolon

Link: https://lore.kernel.org/r/20200421033957.27783-1-yanaijie@huawei.com
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: bfa: Remove set but not used variable 'fchs'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/scsi/bfa/bfa_svc.c: In function 'uf_recv':
drivers/scsi/bfa/bfa_svc.c:5520:17: warning:
 variable 'fchs' set but not used [-Wunused-but-set-variable]
  struct fchs_s *fchs;
                 ^

Link: https://lore.kernel.org/r/20200418071057.96699-1-yuehaibing@huawei.com
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: snic: Make snic_io_exch_ver_cmpl_handler() return void

This function does not need a return value since no callers depend on
it. Make it return void.

This also fixes the coccicheck warning:

drivers/scsi/snic/snic_ctl.c:163:5-8: Unneeded variable: "ret". Return
"0" on line 228

Link: https://lore.kernel.org/r/20200418070615.11603-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: mpt3sas: Remove NULL check before freeing function

Fix the following coccicheck warning:

drivers/scsi/mpt3sas/mpt3sas_base.c:4906:3-19: WARNING: NULL check
before some freeing functions is not needed.

Link: https://lore.kernel.org/r/20200418095850.34883-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: ipr: Remove NULL check before freeing function

Fix the following coccicheck warning:

drivers/scsi/ipr.c:9533:2-18: WARNING: NULL check before some freeing
functions is not needed.

Link: https://lore.kernel.org/r/20200418095903.35118-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: bfa: Remove unneeded semicolon in bfa_fcs_lport_ns_sm_online()

Fix the following coccicheck warning:

drivers/scsi/bfa/bfa_fcs_lport.c:4361:3-4: Unneeded semicolon

Link: https://lore.kernel.org/r/20200418070553.11262-1-yanaijie@huawei.com
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: pmcraid: Replace dma_pool_malloc with dma_pool_zalloc

Replace dma_pool_malloc with dma_pool_zalloc to make the code more concise
in pmcraid_allocate_control_blocks() function.

Link: https://lore.kernel.org/r/1587197241-274646-1-git-send-email-wubo40@huawei.com
Signed-off-by: Wu Bo <wubo40@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: target: iscsi: Remove the iscsi_data_count structure

This patch removes the iscsi_data_count structure and the
iscsit_do_rx_data() function because they are used only by rx_data()

Link: https://lore.kernel.org/r/20200424113913.17237-1-mlombard@redhat.com
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: core: Avoid calling synchronize_rcu() for each device in scsi_host_block()

scsi_host_block() calls scsi_internal_device_block() for each scsi_device and
scsi_internal_device_block() calls blk_mq_quiesce_queue() for each LUN.

Since synchronize_rcu() is called from blk_mq_quiesce_queue(), this can cause
substantial slowdowns on systems with many LUNs.

Use scsi_internal_device_block_nowait() to implement scsi_host_block() so it
is sufficient to run synchronize_rcu() once. This is safe since SCSI does not
set the BLK_MQ_F_BLOCKING flag.

[mkp: commit desc and comment tweaks]

Link: https://lore.kernel.org/r/20200423020713.332743-1-ming.lei@redhat.com
Cc: Steffen Maier <maier@linux.ibm.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dexuan Cui <decui@microsoft.com>
Cc: Hannes Reinecke <hare@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

scsi: BusLogic: Remove conversion to bool in blogic_inquiry()

The '!=' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:

drivers/scsi/BusLogic.c:2240:46-51: WARNING: conversion to bool not
needed here

Link: https://lore.kernel.org/r/20200421034120.28433-1-yanaijie@huawei.com
Acked-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>