The file aic79xx_core.c still contains some FreeBSD-specific code/macro
guards, although cross-compatibility was in theory removed with commit
cca6cb8a ("scsi: aic7xxx: Fix build using bare-metal toolchain").
Remove it.

Link: https://lore.kernel.org/r/20200326193817.12568-1-alex.dewar@gmx.co.ukSigned-off-by: NAlex Dewar <alex.dewar@gmx.co.uk>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

We were setting bActiveICCLevel attribute for UFS device only once but the
type of this attribute has changed from persistent to volatile since UFS
device specification v2.1. This attribute is set to the default value after
power cycle or hardware reset event. It isn't safe to rely on prefetched
data (only used for bActiveICCLevel attribute now). Hence this change
removes the code related to data prefetching and set this parameter on
every attempt to probe the UFS device.
Tested-by: NStanley Chu <stanley.chu@mediatek.com>
Reviewed-by: NStanley Chu <stanley.chu@mediatek.com>
Reviewed-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NCan Guo <cang@codeaurora.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

dc395x_bios_param was only different from the default when the
CONFIG_SCSI_DC395x_TRMS1040_TRADMAP symbol is true, but that symbol doesn't
exist in the Kconfig system and thus can't be set.

Link: https://lore.kernel.org/r/20200325105505.1028582-1-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Fix an error count for active session if the total_cmds is invalid on the
function iscsi_session_setup().  Decrement the number of active sessions
before the funcion return.

Link: https://lore.kernel.org/r/EDBAAA0BBBA2AC4E9C8B6B81DEEE1D6916A28542@DGGEML525-MBS.china.huawei.comReviewed-by: NLee Duncan <lduncan@suuse.com>
Signed-off-by: NWu Bo <wubo40@huawei.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Correct race condition where ioaccel is re-enabled before the raid_map is
updated. For RAID_1, RAID_1ADM, and RAID 5/6 there is a BUG_ON called which
is bad.

 - Change event thread to disable ioaccel only. Send all requests down the
   RAID path instead.

 - Have rescan thread handle offload_enable.

 - Since there is only one rescan allowed at a time, turning
   offload_enabled on/off should not be racy. Each handler queues up a
   rescan if one is already in progress.

  - For timing diagram, offload_enabled is initially off due to a change
    (transformation: splitmirror/remirror), ...

  otbe = offload_to_be_enabled
  oe   = offload_enabled

  Time Event         Rescan              Completion     Request
       Worker        Worker              Thread         Thread
  ---- ------        ------              ----------     -------
   T0   |             |                       + UA      |
   T1   |             + rescan started        | 0x3f    |
   T2   + Event       |                       | 0x0e    |
   T3   + Ack msg     |                       |         |
   T4   |             + if (!dev[i]->oe &&    |         |
   T5   |             |     dev[i]->otbe)     |         |
   T6   |             |      get_raid_map     |         |
   T7   + otbe = 1    |                       |         |
   T8   |             |                       |         |
   T9   |             + oe = otbe             |         |
   T10  |             |                       |         + ioaccel request
   T11                                                  * BUG_ON

  T0 - I/O completion with UA 0x3f 0x0e sets rescan flag.
  T1 - rescan worker thread starts a rescan.
  T2 - event comes in
  T3 - event thread starts and issues "Acknowledge" message
  ...
  T6 - rescan thread has bypassed code to reload new raid map.
  ...
  T7 - event thread runs and sets offload_to_be_enabled
  ...
  T9 - rescan thread turns on offload_enabled.
  T10- request comes in and goes down ioaccel path.
  T11- BUG_ON.

 - After the patch is applied, ioaccel_enabled can only be re-enabled in
   the re-scan thread.

Link: https://lore.kernel.org/r/158472877894.14200.7077843399036368335.stgit@brunhildaReviewed-by: NScott Teel <scott.teel@microsemi.com>
Reviewed-by: NMatt Perricone <matt.perricone@microsemi.com>
Reviewed-by: NScott Benesh <scott.benesh@microsemi.com>
Signed-off-by: NDon Brace <don.brace@microsemi.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

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]

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 76497732 ("cxgb3/l2t: Fix undefined behaviour")

Link: https://lore.kernel.org/r/20200319222533.GA20577@embeddedor.comSigned-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Add PCI shutdown handler support for supporting wake-on-lan feature.

Link: https://lore.kernel.org/r/20200319083811.19499-3-mrangankar@marvell.comSigned-off-by: NManish Rangankar <mrangankar@marvell.com>
Signed-off-by: NNilesh Javali <njavali@marvell.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

This patch adds the mfw error recovery process in the qedi driver. The
process includes a partial/customized driver unload and load to reset
context by preserving active iSCSI session kernel state.

Link: https://lore.kernel.org/r/20200319083811.19499-2-mrangankar@marvell.comSigned-off-by: NManish Rangankar <mrangankar@marvell.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Block layer RPM is enabled for the genernal UFS SCSI devices when they are
probed by their driver. However block layer RPM is not enabled for UFS
well-known SCSI devices.

As UFS SCSI devices have their corresponding BSG char devices, accessing a
BSG char device via IOCTL may send requests to its corresponding SCSI
device through its request queue. If BSG IOCTL sends a request to a
well-known SCSI device when HBA is not runtime active, due to block layer
RPM not being enabled for the well-known SCSI devices, the HBA, which is at
the top of a SCSI device's parent chain, will not be resumed.

This change enables block layer RPM for the well-known SCSI devices so that
block layer can handle RPM for the well-known SCSI devices just like for
the general SCSI devices.
Reviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NCan Guo <cang@codeaurora.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Override devfreq parameters for power-performance trade-off.

Link: https://lore.kernel.org/r/b6875729b6072134985c9113a820cf60a2af22e7.1585160616.git.asutoshd@codeaurora.orgAcked-by: NAvri Altman <Avri.Altman@wdc.com>
Signed-off-by: NAsutosh Das <asutoshd@codeaurora.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Vendor drivers may have a need to update the polling interval and
thresholds.  Provide a vops for vendor drivers to use.

Link: https://lore.kernel.org/r/acd79e00396cff855256adad47f615ccdbde85ac.1585160616.git.asutoshd@codeaurora.orgAcked-by: NAvri Altman <Avri.Altman@wdc.com>
Signed-off-by: NAsutosh Das <asutoshd@codeaurora.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Currently, the frequency that devfreq provides the driver always leads the
clocks to be scaled up.  Hence, round the clock-rate to the nearest
frequency before deciding to scale.

Also update the devfreq statistics of current frequency.

Link: https://lore.kernel.org/r/d0c6c22455811e9f0eda01f9bc70d1398b51b2bd.1585160616.git.asutoshd@codeaurora.orgAcked-by: NAvri Altman <Avri.Altman@wdc.com>
Signed-off-by: NAsutosh Das <asutoshd@codeaurora.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

As a part of sysfs reading of descriptors/attributes/flags, query commands
should only be executed when hba's power runtime status is active.  To
guarantee this, add pm_runtime_get/put_sync() to those paths where query
commands are sent.

Link: https://lore.kernel.org/r/f712a4f7bdb0ae32e0d83634731e7aaa1b3a6cdd.1585009663.git.asutoshd@codeaurora.orgReviewed-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NNitin Rawat <nitirawa@codeaurora.org>
Signed-off-by: NAsutosh Das <asutoshd@codeaurora.org>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

MediaTek platform and UFS controller can dynamically customize the delay
for host enabling according to different scenarios.

For example, if UniPro enters lower-power mode, such delay can be
minimized, otherwise longer delay shall be expected.

Link: https://lore.kernel.org/r/20200318104016.28049-8-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Reduce the waiting period between each HCE (Host Controller Enable) polling
from 5 ms to 1 ms. Also increase the maximum polling times to make "total
polling time" roughly the same.

This change could make HCE initialization faster to improve latency of
ufshcd initialization, error recovery, and resume behaviors.

Link: https://lore.kernel.org/r/20200318104016.28049-7-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NCan Guo <cang@codeaurora.org>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Currently a 1 ms delay is applied before polling CONTROLLER_ENABLE
bit. This delay may not be required or can be changed in different
controllers. Make the delay as a changeable value in struct ufs_hba to
allow it customized by vendors.

Link: https://lore.kernel.org/r/20200318104016.28049-6-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NCan Guo <cang@codeaurora.org>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

A common delay function is introduced in UFS core driver, thus ufs-mediatek
can use it instead of the private delay function.

Link: https://lore.kernel.org/r/20200318104016.28049-5-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Introduce a common delay function to provide flexible way for users to take
choices of udelay and usleep_range into consideration according to the
required delay time.

Link: https://lore.kernel.org/r/20200318104016.28049-4-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NCan Guo <cang@codeaurora.org>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Use an enum to specify the host capabilities instead of #defines inside the
structure definition.

Link: https://lore.kernel.org/r/20200318104016.28049-3-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NCan Guo <cang@codeaurora.org>
Reviewed-by: NBean Huo <beanhuo@micron.com>
Reviewed-by: NAsutosh Das <asutoshd@codeaurora.org>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

In ufshcd_disable_tx_lcc(), if ufshcd_dme_get() or ufshcd_dme_peer_get()
get fail, uninitialized variable "tx_lanes" may be used as unexpected lane
ID for DME configuration.

Fix this issue by initializing "tx_lanes".

Link: https://lore.kernel.org/r/20200318104016.28049-2-stanley.chu@mediatek.comReviewed-by: NAvri Altman <avri.altman@wdc.com>
Reviewed-by: NCan Guo <cang@codeaurora.org>
Reviewed-by: NAsutosh Das <asutoshd@codeaurora.org>
Signed-off-by: NStanley Chu <stanley.chu@mediatek.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

If an iSCSI connection happens to fail while the daemon isn't running (due
to a crash or for another reason), the kernel failure report is not
received.  When the daemon restarts, there is insufficient kernel state in
sysfs for it to know that this happened.  open-iscsi tries to reopen every
connection, but on different initiators, we'd like to know which
connections have failed.

There is session->state, but that has a different lifetime than an iSCSI
connection, so it doesn't directly reflect the connection state.

[mkp: typos]

Link: https://lore.kernel.org/r/20200317233422.532961-1-krisman@collabora.com
Cc: Khazhismel Kumykov <khazhy@google.com>
Suggested-by: NJunho Ryu <jayr@google.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Trace events target_sequencer_start and target_cmd_complete
(include/trace/events/target.h) are ready to show NAA identifier, LUN ID,
and many other important command details in the system log:

TP_printk("%s -> LUN %03u %s data_length %6u  CDB %s  (TA:%s C:%02x)",

However, it's still hard to identify command on the initiator and command
on the target in the real life output of system log.  For that purpose SCSI
provides a command identifier or task tag (term used in previous
standards). This patch adds tag ID in the system log's output:

TP_printk("%s -> LUN %03u tag %#llx %s data_length %6u  CDB %s  (TA:%s C:%02x)",

kworker/1:1-35    [001] ....  1392.989452: target_sequencer_start:
naa.5001405ec1ba6364 -> LUN 001 tag 0x1
SERVICE_ACTION_IN_16 data_length     32
CDB 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00  (TA:SIMPLE C:00)

kworker/1:1-35    [001] ....  1392.989456: target_cmd_complete:
naa.5001405ec1ba6364 <- LUN 001 tag 0x1 status GOOD (sense len 0)
SERVICE_ACTION_IN_16 data_length     32
CDB 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00  (TA:SIMPLE C:00)

Link: https://lore.kernel.org/r/226e01deaa9baf46d6ff3b8698bc9fe881f7dfc1.camel@dubeyko.comReviewed-by: NRoman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: NKonstantin Shelekhin <k.shelekhin@yadro.com>
Reviewed-by: NBart van Assche <bvanassche@acm.org>
Signed-off-by: NViacheslav Dubeyko <v.dubeiko@yadro.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

iscsit_close_session() can only be called when nconn is zero (otherwise a
kernel panic is triggered). If nconn is zero then iscsit_stop_session()
does nothing and exits, so calling it makes no sense.

We still need to call iscsit_check_session_usage_count() because this
function will sleep if the session's refcount is not zero and we don't want
to destroy the session structure if it's still being referenced.

Link: https://lore.kernel.org/r/20200313170656.9716-4-mlombard@redhat.comTested-by: NRahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

A number of hangs have been reported against the target driver; they are
due to the fact that multiple threads may try to destroy the iscsi session
at the same time. This may be reproduced for example when a "targetcli
iscsi/iqn.../tpg1 disable" command is executed while a logout operation is
underway.

When this happens, two or more threads may end up sleeping and waiting for
iscsit_close_connection() to execute "complete(session_wait_comp)".  Only
one of the threads will wake up and proceed to destroy the session
structure, the remaining threads will hang forever.

Note that if the blocked threads are somehow forced to wake up with
complete_all(), they will try to free the same iscsi session structure
destroyed by the first thread, causing double frees, memory corruptions
etc...

With this patch, the threads that want to destroy the iscsi session will
increase the session refcount and will set the "session_close" flag to 1;
then they wait for the driver to close the remaining active connections.
When the last connection is closed, iscsit_close_connection() will wake up
all the threads and will wait for the session's refcount to reach zero;
when this happens, iscsit_close_connection() will destroy the session
structure because no one is referencing it anymore.

 INFO: task targetcli:5971 blocked for more than 120 seconds.
       Tainted: P           OE    4.15.0-72-generic #81~16.04.1
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 targetcli       D    0  5971      1 0x00000080
 Call Trace:
  __schedule+0x3d6/0x8b0
  ? vprintk_func+0x44/0xe0
  schedule+0x36/0x80
  schedule_timeout+0x1db/0x370
  ? __dynamic_pr_debug+0x8a/0xb0
  wait_for_completion+0xb4/0x140
  ? wake_up_q+0x70/0x70
  iscsit_free_session+0x13d/0x1a0 [iscsi_target_mod]
  iscsit_release_sessions_for_tpg+0x16b/0x1e0 [iscsi_target_mod]
  iscsit_tpg_disable_portal_group+0xca/0x1c0 [iscsi_target_mod]
  lio_target_tpg_enable_store+0x66/0xe0 [iscsi_target_mod]
  configfs_write_file+0xb9/0x120
  __vfs_write+0x1b/0x40
  vfs_write+0xb8/0x1b0
  SyS_write+0x5c/0xe0
  do_syscall_64+0x73/0x130
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

Link: https://lore.kernel.org/r/20200313170656.9716-3-mlombard@redhat.comReported-by: NMatt Coleman <mcoleman@datto.com>
Tested-by: NMatt Coleman <mcoleman@datto.com>
Tested-by: NRahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

iscsit_free_session() is equivalent to iscsit_stop_session() followed by a
call to iscsit_close_session().

Link: https://lore.kernel.org/r/20200313170656.9716-2-mlombard@redhat.comTested-by: NRahul Kundu <rahul.kundu@chelsio.com>
Signed-off-by: NMaurizio Lombardi <mlombard@redhat.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

If 'dma_map_single()' fails, the ref counted 'shpnt' will be decremented
twice because 'scsi_host_put()' is called in the if block, and in the error
handling path.

Axe one of these calls.

Link: https://lore.kernel.org/r/20200228215948.7473-1-christophe.jaillet@wanadoo.fr
Fixes: 1dc09e12 ("scsi: aha1740: stop using scsi_unregister")
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Remove code which has no functional use anymore since commit 3c75ad1d
("scsi: qla2xxx: Remove defer flag to indicate immeadiate port loss").

While at it remove also the stale function documentation.

Link: https://lore.kernel.org/r/20200206135443.110701-1-dwagner@suse.deReviewed-by: NArun Easi <aeasi@marvell.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NDaniel Wagner <dwagner@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Removed the common length and introduce read and write length for IOCTL
payload structure.

[mkp: fixed SoB ordering]

Link: https://lore.kernel.org/r/20200316074906.9119-7-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NViswas G <viswas.g@microchip.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Added the sysfs attribute for non fatal log so that management utility can
get the non fatal dump from driver. The non-fatal error is an error
condition or abnormal behavior detected by the host, or detected and
reported by the controller to the host.The non-fatal error does not stop
the controller firmware and enables it to still respond to host requests.
A typical example of a non-fatal error is an I/O timeout or an unusual
error notification from the controller. Since the firmware is operational,
the error dump information is pushed to host memory (by firmware) upon
request from the host.

Link: https://lore.kernel.org/r/20200316074906.9119-6-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

1) Move the instance tracking down after we think the instance is good to
   go. Avoids having a use-after free.

2) There are goto targets for trying to cleanup if the hw fails to
   initialize, but there's some overlap depending on who thinks they own
   the sub-structures.

Link: https://lore.kernel.org/r/20200316074906.9119-5-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NPeter Chang <dpf@google.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

In pm80xx driver, the command mpi_set_phy_profile_req is sent by host
during boot to configure the phy profile such as analog setting page, rate
control page. However, the tag is not freed when its response is
received. As a result, 16 tags are missing for each HBA after boot.  When
NCQ is enabled with queue depth 16, it needs at least, 15 * 16 = 240 tags
for each HBA to achieve the best performance. In current pm80xx driver with
setting CCB_MAX = 256, the total number of tags in each HBA is 255 for data
IO. Hence, without returning those tags to the pool after boot, some device
will finally be forced to non-ncq mode by ATA layer due to excessive errors
(i.e. LLDD cannot allocate tag for queued task).

Link: https://lore.kernel.org/r/20200316074906.9119-4-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Nyuuzheng <yuuzheng@google.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

A kexec reboot causes the controller fw to assert. This assertion shows up
in two ways, the controller doesn't show up as ready and an interrupt is
waiting as soon as the handler is registered. To resolve this added below
fix:

 - Split the interrupt handling setup into two parts, setup and request.

 - If the controller ready register indicates not-ready, but that the not
   readiness is only on the IOC units we can still try a reset to bring the
   system back to the pre-reboot state.

Link: https://lore.kernel.org/r/20200316074906.9119-3-deepak.ukey@microchip.comAcked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NVikram Auradkar <auradkar@google.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Increasing the per-request size maximum (max_sectors_kb) runs into the
per-device DMA scatter gather list limit (max_segments) for users of the io
vector system calls (eg, readv and writev). This is because the kernel
combines io vectors into DMA segments when possible, but it doesn't work
for our user because the vectors in the buffer cache get scrambled.  This
change bumps the advertised max scatter gather length to 528 to cover 2M w/
x86's 4k pages and some extra for the user checksum.  It trims the size of
some of the tables we don't care about and exposes all of the command slots
upstream to the SCSI layer.  Also reduced the PM8001_MAX_CCB to 256 as
pm8001 driver has memory limit depend on machine capability. If we increase
the sg length, we need to trade-off it by decreasing PM8001_MAX_CCB.
PM8001_MAX_CCB = 256 does not have any influence on normal use

Link: https://lore.kernel.org/r/20200316074906.9119-2-deepak.ukey@microchip.comReported-by: Nkbuild test robot <lkp@intel.com>
Acked-by: NJack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: NPeter Chang <dpf@google.com>
Signed-off-by: NDeepak Ukey <deepak.ukey@microchip.com>
Signed-off-by: NViswas G <Viswas.G@microchip.com>
Signed-off-by: NRadha Ramachandran <radha@google.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

Link: https://lore.kernel.org/r/20200315094241.9086-9-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Don Brace <don.brace@microsemi.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

Link: https://lore.kernel.org/r/20200315094241.9086-8-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Reviewed-by: NBart van Assche <bvanassche@acm.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

Also corrected the wrongly passed limit size.  The remaining buffer size
must be decremented.

Link: https://lore.kernel.org/r/20200315094241.9086-7-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Kashyap Desai <kashyap.desai@broadcom.com>
Cc: Sumit Saxena <sumit.saxena@broadcom.com>
Cc: Shivasharan S <shivasharan.srikanteshwara@broadcom.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

Link: https://lore.kernel.org/r/20200315094241.9086-6-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Brian King <brking@us.ibm.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

[mkp: checkpatch fix]

Link: https://lore.kernel.org/r/20200315094241.9086-5-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Achim Leubner <achim_leubner@adaptec.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

Link: https://lore.kernel.org/r/20200315094241.9086-4-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Satish Kharat <satishkh@cisco.com>
Cc: Sesidhar Baddela <sebaddel@cisco.com>
Cc: Karan Tilak Kumar <kartilak@cisco.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>

Since snprintf() returns the would-be-output size instead of the actual
output size, the succeeding calls may go beyond the given buffer limit.
Fix it by replacing with scnprintf().

Link: https://lore.kernel.org/r/20200315094241.9086-3-tiwai@suse.de
Cc: "James E . J . Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K . Petersen" <martin.petersen@oracle.com>
Cc: Subbu Seetharaman <subbu.seetharaman@broadcom.com>
Cc: Ketan Mukadam <ketan.mukadam@broadcom.com>
Cc: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>