Hannes Reinecke [Wed, 13 Jan 2021 09:04:26 +0000 (10:04 +0100)]
scsi: Drop gdth driver
The gdth driver refers to a SCSI parallel, PCI-only HBA RAID adapter which
was manufactured by the now-defunct ICP Vortex company, later acquired by
Adaptec and superseded by the aacraid series of controllers. The driver
itself would require a major overhaul before any modifications can be
attempted, but seeing that it's unlikely to have any users left it should
rather be removed completely.
Ahmed S. Darwish [Sun, 20 Dec 2020 20:36:38 +0000 (21:36 +0100)]
scsi: target: core: Remove in_interrupt() check in transport_handle_cdb_direct()
transport_handle_cdb_direct() uses in_interrupt() to detect if it is safe
to sleep. It produces a stack trace and returns with an error which is
clearly for debugging.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.
transport_handle_cdb_direct() has a comment saying that it may only be
invoked from process context. It invokes transport_generic_new_cmd() which
performs GFP_KERNEL memory allocations. in_interrupt() does not detect all
the contexts where it is invalid to sleep (for the blocking GFP_KERNEL
allocation) as it fails to detect sections with disabled preemption.
Replace the in_interrupt() based check with a might_sleep() annotation.
scsi: target: core: Replace in_interrupt() usage in target_submit_cmd_map_sgls()
target_submit_cmd_map_sgls() uses in_interrupt() to crash if it returns
true.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.
The usage of in_interrupt() is clearly for debugging. might_sleep() is
better at this because it also detects other contexts in which it is not
allowed to sleep, like preempt-disabled section.
scsi: target: alua: Remove in_interrupt() usage in core_alua_check_nonop_delay()
core_alua_check_nonop_delay() uses in_interrupt() to decide if it is safe
to sleep.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.
core_alua_check_nonop_delay() has two callers:
- target_submit_cmd_map_sgls()
Kernel doc says it that it must be called from process context. Also has
a BUG_ON(in_interrupt()).
- iscsit_setup_scsi_cmd()
Invokes iscsit_add_reject_cmd() which does GFP_KERNEL allocation and
target_cmd_init_cdb() which may do GFP_KERNEL allocations.
Remove the in_interrupt() check because all callers are from preemptible
context.
The return value of iscsit_check_session_usage_count() is only checked if
it was not allowed to sleep. If it returns `2' then a timer is prepared. If
it returns something else or if it was allowed to sleep then it is ignored.
Let iscsit_check_session_usage_count() return true if it needs to arm the
timer - otherwise false. This simplifies the code flow of the only caller.
scsi: target: iscsi: Avoid in_interrupt() usage in iscsit_check_session_usage_count()
iscsit_check_session_usage_count() uses in_interrupt() to find out if it is
safe to invoke wait_for_completion().
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.
There is only one caller of iscsit_check_session_usage_count() which
already has an argument indicating if it is safe to sleep.
Extend iscsit_check_session_usage_count() by an argument indicating if it
may sleep.
scsi: target: iscsi: Avoid in_interrupt() usage in iscsit_close_session()
iscsit_close_session() uses in_interrupt() to decide if it needs to check
the return value of iscsit_check_session_usage_count() if it was not able
to sleep.
The usage of in_interrupt() in drivers is phased out and Linus clearly
requested that code which changes behaviour depending on context should
either be separated or the context be conveyed in an argument passed by the
caller, which usually knows the context.
iscsit_close_session() has two callers:
- iscsit_handle_time2retain_timeout()
A timer_list callback.
- iscsit_close_connection()
Runs in preemptible context, acquires a mutex.
Add an argument to iscsit_close_session() indicating if sleeping is
possible.
Stanley Chu [Wed, 20 Jan 2021 15:01:41 +0000 (23:01 +0800)]
scsi: ufs: Remove redundant null checking of devfreq instance
hba->devfreq is zero-initialized thus it is not required to check its
existence in ufshcd_add_lus() function which is invoked during
initialization only.
Stanley Chu [Wed, 20 Jan 2021 15:01:40 +0000 (23:01 +0800)]
scsi: ufs: Refactor cancelling clkscaling works
Cancelling suspend_work and resume_work is only required while suspending
clk-scaling. Move these two invocations into ufshcd_suspend_clkscaling()
function.
Can Guo [Wed, 20 Jan 2021 10:04:23 +0000 (02:04 -0800)]
Revert "Make sure clk scaling happens only when HBA is runtime ACTIVE"
Commit 73cc291c2702 ("scsi: ufs: Make sure clk scaling happens only
when HBA is runtime ACTIVE") is no longer needed since commit 0e9d4ca43ba8 ("scsi: ufs: Protect some contexts from unexpected clock
scaling") is a more mature fix to protect UFS LLD stability from clock
scaling invoked through sysfs nodes by users.
ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and
ufshcd_exit_clk_gating(). Move ufshcd_exit_clk_scaling/gating() to
ufshcd_hba_exit(). Meanwhile, add dedicated functions to initialize
and remove sysfs nodes of clock scaling/gating to make the code more
readable. Overall functionality remains same.
Can Guo [Wed, 20 Jan 2021 10:04:21 +0000 (02:04 -0800)]
scsi: ufs: Protect some contexts from unexpected clock scaling
In contexts like suspend, shutdown, and error handling we need to
suspend devfreq to make sure these contexts won't be disturbed by
clock scaling. However, suspending devfreq is not enough since users
can still trigger a clock scaling by manipulating the devfreq sysfs
nodes like min/max_freq and governor even after devfreq is
suspended. Moreover, mere suspending devfreq cannot synchroinze a
clock scaling which has already been invoked through these sysfs
nodes. Add one more flag in struct clk_scaling and wrap the entire
func ufshcd_devfreq_scale() with the clk_scaling_lock, so that we can
use this flag and clk_scaling_lock to control and synchronize clock
scaling invoked through devfreq sysfs nodes.
Bean Huo [Tue, 19 Jan 2021 16:38:46 +0000 (17:38 +0100)]
scsi: ufs: Group UFS WB related flags in struct ufs_dev_info
UFS device-related flags should be grouped in ufs_dev_info. Move wb_enabled
and wb_buf_flush_enabled out from struct ufs_hba, group them in struct
ufs_dev_info, and align the names of the structure members vertically.
Link: https://lore.kernel.org/r/20210119163847.20165-6-huobean@gmail.com Reviewed-by: Can Guo <cang@codeaurora.org> Acked-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bean Huo [Tue, 19 Jan 2021 16:38:45 +0000 (17:38 +0100)]
scsi: ufs: Remove two WB related fields from struct ufs_dev_info
d_wb_alloc_units and d_ext_ufs_feature_sup are only used during WB probe.
They are used to confirm the condition that "if bWriteBoosterBufferType
is set to 01h but dNumSharedWriteBoosterBufferAllocUnits is set to zero,
the WriteBooster feature is disabled", and if UFS device supports WB.
Bean Huo [Tue, 19 Jan 2021 16:38:44 +0000 (17:38 +0100)]
scsi: ufs: Update comment in the function ufshcd_wb_probe()
USFHCD supports both WriteBooster "LU dedicated buffer" mode and "shared
buffer" mode. Update the comment accordingly in the function
ufshcd_wb_probe().
Link: https://lore.kernel.org/r/20210119163847.20165-4-huobean@gmail.com Reviewed-by: Can Guo <cang@codeaurora.org> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bean Huo [Tue, 19 Jan 2021 16:38:42 +0000 (17:38 +0100)]
scsi: ufs: Add "wb_on" sysfs node to control WB on/off
Currently UFS WriteBooster driver uses clock scaling up/down to set WB
on/off. For the platforms which don't support UFSHCD_CAP_CLK_SCALING, WB
will be always on. Provide a sysfs attribute to enable/disable WB during
runtime. Write 1/0 to "wb_on" sysfs node to enable/disable UFS WB.
Link: https://lore.kernel.org/r/20210119163847.20165-2-huobean@gmail.com Reviewed-by: Avri Altman <avri.altman@wdc.com> Reviewed-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Kiwoong Kim [Tue, 19 Jan 2021 03:33:42 +0000 (12:33 +0900)]
scsi: ufs: ufs-exynos: Use UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE
Exynos needs scatterlist entries aligned to page size because it isn't
capable of transferring data contained in one DATA IN operation to seversal
areas in memory.
Kiwoong Kim [Tue, 19 Jan 2021 03:33:41 +0000 (12:33 +0900)]
scsi: ufs: Introduce a quirk to allow only page-aligned sg entries
Some SoCs require a single scatterlist entry for smaller than page size,
i.e. 4KB. When dispatching commands with more than one scatterlist entry
under 4KB in size the following behavior is observed:
A command to read a block range is dispatched with two scatterlist entries
that are named AAA and BBB. After dispatching, the host builds two PRDT
entries and during transmission, device sends just one DATA IN because
device doesn't care about host DMA. The host then transfers the combined
amount of data from start address of the area named AAA. As a consequence,
the area that follows AAA in memory would be corrupted.
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag. It has been compile
tested.
When memory is allocated in 'pm8001_init_ccb_tag()' GFP_KERNEL can be used
because this function already uses this flag a few lines above.
While at it, remove "pm80xx: " in a debug message. 'pm8001_dbg()' already
adds the driver name in the message.
Colin Ian King [Fri, 15 Jan 2021 09:58:24 +0000 (09:58 +0000)]
scsi: pm80xx: Clean up indentation of a code block
A block of code is indented one level too deeply, clean this up.
Link: https://lore.kernel.org/r/20210115095824.9170-1-colin.king@canonical.com Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Addresses-Coverity: ("Indentation does not match nesting level")
Muneendra Kumar [Wed, 6 Jan 2021 21:49:06 +0000 (03:19 +0530)]
scsi: scsi_transport_fc: Add a new rport state FC_PORTSTATE_MARGINAL
Add a new interface, fc_eh_should_retry_cmd(), which checks if the cmd
should be retried or not by checking the rport state. If the rport state is
marginal it returns false to make sure there won't be any retries on the
cmd.
Make the fc_remote_port_delete(), fc_user_scan_tgt(), and
fc_timeout_deleted_rport() functions handle the new rport state.
Link: https://lore.kernel.org/r/1609969748-17684-4-git-send-email-muneendra.kumar@broadcom.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Muneendra Kumar [Wed, 6 Jan 2021 21:49:05 +0000 (03:19 +0530)]
scsi: core: No retries on abort success
Add a new optional routine, eh_should_retry_cmd(), in scsi_host_template
that allows the transport to decide if a cmd is retryable. Return true if
the transport is in a state the cmd should be retried on.
Update scmd_eh_abort_handler() and scsi_eh_flush_done_q() to both call
scsi_eh_should_retry_cmd() to check whether the command needs to be
retried.
The above changes were based on a patch by Mike Christie.
Link: https://lore.kernel.org/r/1609969748-17684-3-git-send-email-muneendra.kumar@broadcom.com Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Muneendra Kumar <muneendra.kumar@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:48 +0000 (14:31 -0600)]
scsi: ibmvfc: Provide modules parameters for MQ settings
Add the various module parameter toggles for adjusting the MQ
characteristics at boot/load time as well as a device attribute for
changing the client scsi channel request amount.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:47 +0000 (14:31 -0600)]
scsi: ibmvfc: Enable MQ and set reasonable defaults
Turn on MQ by default and set sane values for the upper limit on hw queues
for the SCSI host, and number of hw SCSI channels to request from the
partner VIOS.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:45 +0000 (14:31 -0600)]
scsi: ibmvfc: Send Cancel MAD down each hw SCSI channel
In general the client needs to send Cancel MADs and task management
commands down the same channel as the command(s) intended to cancel or
abort. The client assigns cancel keys per LUN and thus must send a Cancel
down each channel commands were submitted for that LUN. Further, the client
then must wait for those cancel completions prior to submitting a LUN RESET
or ABORT TASK SET.
Add a cancel rsp iu syncronization field to the ibmvfc_queue struct such
that the cancel routine can sync the cancel response to each queue that
requires a cancel command. Build a list of each cancel event sent and wait
for the completion of each submitted cancel.
Add a helper routine for initializing a Cancel MAD. This will be useful for
a channelized client that needs to send Cancel commands down every channel
commands were sent for a particular LUN.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:43 +0000 (14:31 -0600)]
scsi: ibmvfc: Register Sub-CRQ handles with VIOS during channel setup
If the ibmvfc client adapter requests channels it must submit a number of
Sub-CRQ handles matching the number of channels being requested. The VIOS
in its response will overwrite the actual number of channel resources
allocated which may be less than what was requested. The client then must
store the VIOS Sub-CRQ handle for each queue. This VIOS handle is needed as
a parameter with h_send_sub_crq().
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:42 +0000 (14:31 -0600)]
scsi: ibmvfc: Send commands down HW Sub-CRQ when channelized
When the client has negotiated the use of channels all vfcFrames are
required to go down a Sub-CRQ channel or it is a protocoal violation. If
the adapter state is channelized submit vfcFrames to the appropriate
Sub-CRQ via the h_send_sub_crq() helper.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:41 +0000 (14:31 -0600)]
scsi: ibmvfc: Set and track hw queue in ibmvfc_event struct
Extract the hwq id from a SCSI command and store it in the ibmvfc_event
structure to identify which Sub-CRQ to send the command down when channels
are being utilized.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:40 +0000 (14:31 -0600)]
scsi: ibmvfc: Advertise client support for using hardware channels
Previous patches have plumbed the necessary Sub-CRQ interface and channel
negotiation MADs to fully channelize via hardware backed queues.
Advertise client support via NPIV Login capability IBMVFC_CAN_USE_CHANNELS
when the client bits have MQ enabled via vhost->mq_enabled, or when
channels were already in use during a subsequent NPIV Login. The later is
required because channel support is only renegotiated after a CRQ pair is
broken. Simple NPIV Logout/Logins require the client to continue to
advertise the channel capability until the CRQ pair between the client is
broken.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:39 +0000 (14:31 -0600)]
scsi: ibmvfc: Implement channel enquiry and setup commands
New NPIV_ENQUIRY_CHANNEL and NPIV_SETUP_CHANNEL management datagrams (MADs)
were defined in a previous patchset. If the client advertises a desire to
use channels and the partner VIOS is channel capable then the client must
proceed with channel enquiry to determine the maximum number of channels
the VIOS is capable of providing, and registering SubCRQs via channel setup
with the VIOS immediately following NPIV Login. This handshaking should not
be performed for subsequent NPIV Logins unless the CRQ connection has been
reset.
Implement these two new MADs and issue them following a successful NPIV
login where the VIOS has set the SUPPORT_CHANNELS capability bit in the
NPIV Login response.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:38 +0000 (14:31 -0600)]
scsi: ibmvfc: Map/request irq and register Sub-CRQ interrupt handler
Create an irq mapping for the hw_irq number provided from phyp firmware.
Request an irq assigned our Sub-CRQ interrupt handler. Unmap these irqs at
Sub-CRQ teardown.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:34 +0000 (14:31 -0600)]
scsi: ibmvfc: Add alloc/dealloc routines for SCSI Sub-CRQ Channels
Allocate a set of Sub-CRQs in advance. During channel setup the client and
VIOS negotiate the number of queues the VIOS supports and the number that
the client desires to request. Its possible that the final channel
resources allocated is less than requested, but the client is still
responsible for sending handles for every queue it is hoping for.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:33 +0000 (14:31 -0600)]
scsi: ibmvfc: Add Subordinate CRQ definitions
Subordinate Command Response Queues (Sub CRQ) are used in conjunction with
the primary CRQ when more than one queue is needed by the virtual I/O
adapter. Recent phyp firmware versions support Sub CRQ's with ibmvfc
adapters. This feature is a prerequisite for supporting multiple hardware
backed submission queues in the vfc adapter.
The Sub CRQ command element differs from the standard CRQ in that it is
32bytes long as opposed to 16bytes for the latter. Despite this extra
16bytes the ibmvfc protocol will use the original CRQ command element
mapped to the first 16bytes of the Sub CRQ element initially.
Add definitions for the Sub CRQ command element and queue.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:30 +0000 (14:31 -0600)]
scsi: ibmvfc: Init/free event pool during queue allocation/free
The event pool and CRQ used to be separate entities of the adapter host
structure and as such were allocated and freed independently of each
other. Recent work as defined a generic queue structure with an event pool
specific to each queue. As such the event pool for each queue shouldn't be
allocated/freed independently, but instead performed as part of the queue
allocation/free routines.
Move the calls to ibmvfc_event_pool_{init|free} into
ibmvfc_{alloc|free}_queue respectively. The only functional change here is
that the CRQ cannot be released in ibmvfc_remove until after the event pool
has been successfully purged since releasing the queue will also free the
event pool.
Tyrel Datwyler [Thu, 14 Jan 2021 20:31:29 +0000 (14:31 -0600)]
scsi: ibmvfc: Move event pool init/free routines
The next patch in this series reworks the event pool allocation calls to
happen within the individual queue allocation routines instead of as
independent calls.
Move the init/free routines earlier in ibmvfc.c to prevent undefined
reference errors when calling these functions from the queue allocation
code. No functional change.
Can Guo [Thu, 14 Jan 2021 03:13:28 +0000 (19:13 -0800)]
scsi: ufs: Protect PM ops and err_handler from user access through sysfs
User layer may access sysfs nodes when system PM ops or error handling is
running. This can cause various problems. Rename eh_sem to host_sem and use
it to protect PM ops and error handling from user layer intervention.
Can Guo [Thu, 14 Jan 2021 03:13:27 +0000 (19:13 -0800)]
scsi: ufs: Fix a possible NULL pointer issue
During system resume/suspend, hba could be NULL. In this case, do not touch
eh_sem.
Fixes: 88a92d6ae4fe ("scsi: ufs: Serialize eh_work with system PM events and async scan") Link: https://lore.kernel.org/r/1610594010-7254-2-git-send-email-cang@codeaurora.org Acked-by: Stanley Chu <stanley.chu@mediatek.com> Signed-off-by: Can Guo <cang@codeaurora.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
John Garry [Tue, 12 Jan 2021 11:11:30 +0000 (19:11 +0800)]
scsi: MAINTAINERS: Remove intel-linux-scu@intel.com for INTEL C600 SAS DRIVER
The mail address intel-linux-scu@intel.com bounces. Remove it.
Link: https://lore.kernel.org/r/1610449890-198089-1-git-send-email-john.garry@huawei.com Cc: Ahmed S. Darwish <a.darwish@linutronix.de> Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com> Acked-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Jaegeuk Kim [Mon, 11 Jan 2021 09:59:27 +0000 (01:59 -0800)]
scsi: ufs: WB is only available on LUN #0 to #7
Kernel stack violation when getting unit_descriptor/wb_buf_alloc_units from
rpmb LUN. The reason is that the unit descriptor length is different per
LU.
The length of Normal LU is 45 while the one of rpmb LU is 35.
int ufshcd_read_desc_param(struct ufs_hba *hba, ...)
{
param_offset=41;
param_size=4;
buff_len=45;
...
buff_len=35 by rpmb LU;
if (is_kmalloc) {
/* Make sure we don't copy more data than available */
if (param_offset + param_size > buff_len)
param_size = buff_len - param_offset;
--> param_size = 250;
memcpy(param_read_buf, &desc_buf[param_offset], param_size);
--> memcpy(param_read_buf, desc_buf+41, 250);
[ 141.868974][ T9174] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: wb_buf_alloc_units_show+0x11c/0x11c
}
}
Quinn Tran [Mon, 11 Jan 2021 09:31:32 +0000 (01:31 -0800)]
scsi: qla2xxx: Fix mailbox Ch erroneous error
Mailbox Ch/dump ram extend expects mb register 10 to be set. If not
set/clear, firmware can pick up garbage from previous invocation of this
mailbox. Example: mctp dump can set mb10. On subsequent flash read which
use mailbox cmd Ch, mb10 can retain previous value.
Saurav Kashyap [Mon, 11 Jan 2021 09:31:28 +0000 (01:31 -0800)]
scsi: qla2xxx: Implementation to get and manage host, target stats and initiator port
This statistics will help in debugging process and checking specific error
counts. It also provides a capability to isolate the port or bring it out
of isolation.
Link: https://lore.kernel.org/r/20210111093134.1206-2-njavali@marvell.com Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Saurav Kashyap <skashyap@marvell.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Sergey Shtylyov [Sun, 10 Jan 2021 16:46:59 +0000 (19:46 +0300)]
scsi: aha1542: Clarify 'struct ccb' comments
This driver's original authors did pretty bad job of documenting the
Command Control Block (CCB) structure -- especially its 2nd byte, where the
bit numbers were completely left out. Sync up the 'struct ccb' comments to
the Adaptec AHA-154xA manual.
Pavel Begunkov [Sat, 9 Jan 2021 15:53:27 +0000 (15:53 +0000)]
scsi: target: file: Don't zero iter before iov_iter_bvec
iov_iter_bvec() initialises iterators well, no need to pre-zero it
beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it out
and generate extra code for that (confirmed with assembly).
scsi: pm80xx: Log SATA IOMB completion status on failure
Added a log message in SATA completion path to capture the status of failed
command. If the status does not match any expected status, another message
will be logged.
On IO failure with known status, the log message will be:
[ 1712.951735] pm80xx0:: mpi_sata_completion 2269: IO failed device_id 16385 status 0x1 tag XX
If the firmware returns unexpected status, a message of the following
format will be logged:
[ 1712.951735] pm80xx0:: mpi_sata_completion XXXX: Unknown status device_id XXXXX status 0xX tag XX
Link: https://lore.kernel.org/r/20210109123849.17098-8-Viswas.G@microchip.com Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: Vishakha Channapattan <vishakhavc@google.com> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by: Ashokkumar N <Ashokkumar.N@microchip.com> Signed-off-by: Radha Ramachandran <radha@google.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
scsi: pm80xx: Simultaneous poll for all FW readiness
In check_fw_ready() we first wait for ILA to come up and then we wait for
RAAE to come up and IOPs and so on. This is a sequential check. Because of
this, ILA image seems to be not ready in the allocated time and so the
driver marks it as "not ready" and then moves on to other FW images.
ILA does become ready eventually, but is not checked again. The driver
concludes that FW is not ready when it actually is.
Instead of sequentially polling each image, we keep polling for all images
to be ready. The timeout for the polling has been set to the sum of what
was used for each individual image.
Link: https://lore.kernel.org/r/20210109123849.17098-7-Viswas.G@microchip.com Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: Bhavesh Jashnani <bjashnani@google.com> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by: Ashokkumar N <Ashokkumar.N@microchip.com> Signed-off-by: Radha Ramachandran <radha@google.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Viswas G [Sat, 9 Jan 2021 12:38:46 +0000 (18:08 +0530)]
scsi: pm80xx: Fix driver fatal dump failure
The function pm80xx_get_fatal_dump() has two issues that result in the
fatal dump not being able to complete successfully.
1. Trying to collect fatal_logs from the application fails because we are
not shifting the MEMBASE-II register properly. Once we read 64K region
of data we have to shift the MEMBASE-II register and read the next
chunk. Only then would we be able to get complete data.
2. If a timeout occurs, our application will get stuck.
Link: https://lore.kernel.org/r/20210109123849.17098-6-Viswas.G@microchip.com Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by: Ashokkumar N <Ashokkumar.N@microchip.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
akshatzen [Sat, 9 Jan 2021 12:38:44 +0000 (18:08 +0530)]
scsi: pm80xx: Check main config table address
The driver initializes main configuration, general status, inbound queue
and outbound queue table addresses based on a value read from
MSGU_SCRATCH_PAD_0 register.
We should validate these addresses before dereferencing them.
Adds two validations:
1. Check if main configuration table offset lies within the pcibar
mapped
2. Check if first dword of main configuration table reads "PMCS"
There are two calls to init_pci_device_addresses() done during
pm8001_pci_probe() in this sequence:
1. First inside chip_soft_rst, where if init_pci_device_addresses fails we
will go ahead assuming MPI state is not ready and reset the device as
long as bootloader is okay. This gives chance to second call of
init_pci_device_addresses to set up the addresses after reset.
2. The second call is via pm80xx_chip_init, after soft reset is done and
firmware is checked to be ready. Once that is done we are safe to go
ahead and initialize default table values and use them.
Tests:
1. Enabled debugging logs and observed no issues during initialization,
with a controller with no issues:
akshatzen [Sat, 9 Jan 2021 12:38:43 +0000 (18:08 +0530)]
scsi: pm80xx: Check for fatal error
When the controller runs into a fatal error, commands get stuck due to no
response. If the controller is in fatal error state, abort requests issued
to the controller get stuck too.
Check the controller state for fatal error conditions.
Link: https://lore.kernel.org/r/20210109123849.17098-3-Viswas.G@microchip.com Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: akshatzen <akshatzen@google.com> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by: Radha Ramachandran <radha@google.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
akshatzen [Sat, 9 Jan 2021 12:38:42 +0000 (18:08 +0530)]
scsi: pm80xx: Do not busy wait in MPI init check
We do not need to busy wait during mpi_init_check() since it is not being
invoked in atomic context. mpi_init_check() is being called from
pm8001_pci_resume(), pm8001_pci_probe(). Hence we are replacing udelay with
msleep.
Link: https://lore.kernel.org/r/20210109123849.17098-2-Viswas.G@microchip.com Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by: akshatzen <akshatzen@google.com> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Ruksar Devadi <Ruksar.devadi@microchip.com> Signed-off-by: Radha Ramachandran <radha@google.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
YANG LI [Wed, 30 Dec 2020 07:04:20 +0000 (15:04 +0800)]
scsi: isci: Remove the unneeded variable "status"
The variable 'status' is being initialized with SCI_SUCCESS and never
updated later with a new value. The initialization is redundant and can be
removed.
Adrian Hunter [Thu, 7 Jan 2021 07:25:38 +0000 (09:25 +0200)]
scsi: ufs: ufs-debugfs: Add error counters
People testing have a need to know how many errors might be occurring over
time. Add error counters and expose them via debugfs.
A module initcall is used to create a debugfs root directory for
ufshcd-related items. In the case that modules are built-in, then
initialization is done in link order, so move ufshcd-core to the top of the
Makefile.
Link: https://lore.kernel.org/r/20210107072538.21782-1-adrian.hunter@intel.com Reviewed-by: Avri Altman <avri.altman@wdc.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Reviewed-by: Can Guo <cang@codeaurora.org> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
scsi: storvsc: Resolve data race in storvsc_probe()
vmscsi_size_delta can be written concurrently by multiple instances of
storvsc_probe(), corresponding to multiple synthetic IDE/SCSI devices;
cf. storvsc_drv's probe_type == PROBE_PREFER_ASYNCHRONOUS. Change the
global variable vmscsi_size_delta to per-synthetic-IDE/SCSI-device.
Link: https://lore.kernel.org/r/20201217203321.4539-3-parri.andrea@gmail.com Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Suggested-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
scsi: storvsc: Fix max_outstanding_req_per_channel for Win8 and newer
Current code overestimates the value of max_outstanding_req_per_channel for
Win8 and newer hosts, since vmscsi_size_delta is set to the initial value
of sizeof(vmscsi_win8_extension) rather than zero. This may lead to wrong
decisions when using ring_avail_percent_lowater equals to zero. The
estimate of max_outstanding_req_per_channel is 'exact' for Win7 and older
hosts. A better choice, keeping the algorithm for the estimation simple,
is to err the other way around, i.e., to underestimate for Win7 and older
but to use the exact value for Win8 and newer.
Link: https://lore.kernel.org/r/20201217203321.4539-2-parri.andrea@gmail.com Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Suggested-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
James Smart [Mon, 4 Jan 2021 18:02:40 +0000 (10:02 -0800)]
scsi: lpfc: Update lpfc version to 12.8.0.7
Update lpfc version to 12.8.0.7
Link: https://lore.kernel.org/r/20210104180240.46824-16-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:39 +0000 (10:02 -0800)]
scsi: lpfc: Enhancements to LOG_TRACE_EVENT for better readability
While testing recent discovery node rework, several items were seen that
could be done better with respect to the new trace event logic.
1) in the following msg:
kernel: lpfc 0000:44:00.0: start 35 end 35 cnt 0
If cnt is zero in the 1st message, there is no reason to display the
1st message, which is just giving start/end positioning.
Fix by not displaying message if cnt is 0.
2) If the driver is loaded with module log verbosity off, and later a
single NPIV host instance verbosity is enabled via sysfs, it enables
messages on all instances. This is due to the trace log verbosity checks
(lpfc_dmp_dbg) looking at the phba only. It should look at the phba and
the vport.
Fix by enabling a check on both phba and vport.
3) in the following messages:
2904 Firmware Dump Image Present on Adapter
2887 Reset Needed: Attempting Port Recovery...
These messages are not necessary for the trace event log, which is
primarily for discovery.
Fix by changing log level on these 2 messages to LOG_SLI.
Link: https://lore.kernel.org/r/20210104180240.46824-15-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:38 +0000 (10:02 -0800)]
scsi: lpfc: Implement health checking when aborting I/O
Several errors have occurred where the adapter stops or fails but does not
raise the register values for the driver to detect failure. Thus driver is
unaware of the failure. The failure typically results in I/O timeouts, the
I/O timeout handler failing (after several seconds), and the error handler
escalating recovery policy and resulting in more errors. Eventually, the
driver is in a position where things have spiraled and it can't do recovery
because other recovery ops are still outstanding and it becomes unusable.
Resolve the situation by having the I/O timeout handler (actually a els,
SCSI I/O, NVMe ls, or NVMe I/O timeout), in addition to aborting the I/O,
perform a mailbox command and look for a response from the hardware. If
the mailbox command fails, it will mark the adapter offline and then invoke
the adapter reset handler to clean up.
The new I/O timeout test will be limited to a test every 5s. If there are
multiple I/O timeouts concurrently, only the 1st I/O timeout will generate
the mailbox command. Further testing will only occur once a timeout occurs
after a 5s delay from the last mailbox command has expired.
Link: https://lore.kernel.org/r/20210104180240.46824-14-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:37 +0000 (10:02 -0800)]
scsi: lpfc: Fix crash when nvmet transport calls host_release
When lpfc is running in NVMET mode and supports the NVME-1 addendum
changes, a LIP on a bound NVME Initiator or lipping the lpfc NVMET's link
resulted in an Oops in lpfc_nvmet_host_release.
The fix requires lpfc NVMET to maintain an additional reference on any node
structure that acts as the hosthandle for the NVMET transport. This
reference get is a one-time addition, is taken prior to the upcall of an
unsolicited LS_REQ, and is released when the NVMET transport releases the
hosthandle during the host_release downcall.
Link: https://lore.kernel.org/r/20210104180240.46824-13-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:36 +0000 (10:02 -0800)]
scsi: lpfc: Fix vport create logging
When with testing with large numbers of npiv vports and link bounces, the
driver is flooding the messages file, even with log_verbose = 0.
The new LOG_TRACE_EVENT messages are still generating events to the
messages files.
Fix by converting the vport create msg from LOG_TRACE_EVENT to LOG_VPORT.
Link: https://lore.kernel.org/r/20210104180240.46824-12-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:35 +0000 (10:02 -0800)]
scsi: lpfc: Fix NVMe recovery after mailbox timeout
If a mailbox command times out, the SLI port is deemed in error and the
port is reset. The HBA cleanup is not returning I/Os to the NVMe layer
before the port is unregistered. This is due to the HBA being marked
offline (!SLI_ACTIVE) and cleanup being done by the mailbox timeout handler
rather than an general adapter reset routine. The mailbox timeout handler
mailbox handler only cleaned up SCSI I/Os.
Fix by reworking the mailbox handler to:
- After handling the mailbox error, detect the board is already in
failure (may be due to another error), and leave cleanup to the
other handler.
- If the mailbox command timeout is initial detector of the port error,
continue with the board cleanup and marking the adapter offline
(!SLI_ACTIVE). Remove the SCSI-only I/O cleanup routine. The generic
reset adapter routine that is subsequently invoked, will clean up the
I/Os.
- Have the reset adapter routine flush all NVMe and SCSI I/Os if the
adapter has been marked failed (!SLI_ACTIVE).
- Rework the NVMe I/O terminate routine to take a status code to fail the
I/O with and update so that cleaned up I/O calls the wqe completion
routine. Currently it is bypassing the wqe cleanup and calling the NVMe
I/O completion directly. The wqe completion routine will take care of
data structure and node cleanup then call the NVMe I/O completion
handler.
Link: https://lore.kernel.org/r/20210104180240.46824-11-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:34 +0000 (10:02 -0800)]
scsi: lpfc: Fix target reset failing
Target reset is failed by the target as an invalid command.
The Target Reset TMF has been obsoleted in T10 for a while, but continues
to be used. On (newer) devices, the TMF is rejected causing the reset
handler to escalate to adapter resets.
Fix by having Target Reset TMF rejections be translated into a LOGO and
re-PLOGI with the target device. This provides the same semantic action
(although, if the device also supports nvme traffic, it will terminate nvme
traffic as well - but it's still recoverable).
Link: https://lore.kernel.org/r/20210104180240.46824-10-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:33 +0000 (10:02 -0800)]
scsi: lpfc: Fix error log messages being logged following SCSI task mgnt
A successful task mgmt command is logging errors, making it look like
problems were encountered. This is due to log messages for the
device/target and bus reset handlers having the LOG_TRACE_EVENT flag set.
Fix by adjusting the event flag such that the call to the logging routine
only receives a LOG_TRACE_EVENT if a prior call actually failed.
Link: https://lore.kernel.org/r/20210104180240.46824-9-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:32 +0000 (10:02 -0800)]
scsi: lpfc: Prevent duplicate requests to unregister with cpuhp framework
In the lpfc offline routine, called for various reasons such as sysfs
attribute, driver unload, or port error, the driver is calling
__lpfc_cpuhp_remove() to destroy the hot plug data. If the offline routine
is called while the driver is in the process of being unloaded, a request
using lpfc_cpuhp_remove() is also made from lpfc_sli4_hba_unset(). The
cpuhp elements are no longer valid when the second removal request is made.
Fix by only calling the cpuhp removal once when the adapter is in the
process of unloading.
Link: https://lore.kernel.org/r/20210104180240.46824-8-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:31 +0000 (10:02 -0800)]
scsi: lpfc: Fix FW reset action if I/Os are outstanding
If the port is configured for NVME and has any outstanding IOs when a FW
reset is requesteed, outstanding I/Os are not properly cleaned up. This
causes the fw download request to fail.
Fix by clearing the LPFC_SLI_ACTIVE flag to signify the I/O must be
manually flushed by the driver on port reset.
Link: https://lore.kernel.org/r/20210104180240.46824-7-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:30 +0000 (10:02 -0800)]
scsi: lpfc: Use the nvme-fc transport supplied timeout for LS requests
When lpfc generates a GEN_REQUEST wqe for the nvme LS (such as Create
Association), the timeout is set to R_A_TOV without regard to the timeout
value supplied by the nvme-fc transport. The driver should be setting the
timeout to the value passed into the routine. Additionally the caller
should be setting the timeout value to the value in the ls request set by
the nvme transport. Instead, it unconditionally is setting it to a driver
defined value. So the driver actually overrode the value twice.
Fix by using the timeout provided to the routine, and for the caller, set
the timeout to the ls request timeout value.
Link: https://lore.kernel.org/r/20210104180240.46824-6-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:29 +0000 (10:02 -0800)]
scsi: lpfc: Fix crash when a fabric node is released prematurely
The driver's management of the fabric controller (aka pseudo-scsi
initiator) node in SLI3 mode is causing this crash. The crash occurs
because of a node reference imbalance that frees the fabric controller node
while devloss is outstanding from the SCSI transport. This is triggered by
an odd behavior where the switch reacts to a rejected RDP request with a
PLOGI and nothing else, not even a LOGO. The driver ACKS the PLOGI and
after successfully registering the RPI, incorrectly registers the fabric
controller node because it has the NLP_FC4_FCP flag still set from the
fabric controller PRLI. If a LIP is issued, the driver attempts to cleanup
on Link Up and ends up executing too many puts.
Fix by detecting the fabric node type and clearing out the nodes internal
flags that triggered a SCSI transport registration and subsequence dev_loss
event. The driver cannot count on any persistence from fabric controller
nodes.
Link: https://lore.kernel.org/r/20210104180240.46824-5-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:28 +0000 (10:02 -0800)]
scsi: lpfc: Refresh ndlp when a new PRLI is received in the PRLI issue state
Testing with target ports coming and going, the driver eventually reached a
state where it no longer discovered the target. When the driver has issued
a PRLI and receives a PRLI from the target, it is not properly updating the
node's initiator/target role flags. Thus, when a subsequent RSCN is
received for a target loss, the driver mis-identifies the target as an
initiator and does not initiate LUN scanning.
Fix by always refreshing the ndlp with the latest PRLI state information
whenever a PRLI is processed. Also clear the ndlp flags when processing a
PLOGI so that there is no carry over through a re-login.
Link: https://lore.kernel.org/r/20210104180240.46824-4-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:27 +0000 (10:02 -0800)]
scsi: lpfc: Fix auto sli_mode and its effect on CONFIG_PORT for SLI3
A very long time ago, there was a feature: auto sli mode. It gave the user
the ability to auto select the SLI mode (SLI2 or SLI3) to run the port in,
or even force SLI2 mode if configured. Because of the convoluted logic,
the CONFIG_PORT mbox command ends up being called 2 or 3 times. It should
have been called only once. Additionally, the driver no longer supports
SLI-2, so only SLI-3 mode should be allowed.
The following changes were made:
- Force module parameter to SLI3 only.
- Rip out redundant CONFIG_PORT mbox commands.
- Force CONFIG_PORT mbox command to be in beginning of enable ISR routine.
- Added changes for offline to online behavior
Link: https://lore.kernel.org/r/20210104180240.46824-3-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
James Smart [Mon, 4 Jan 2021 18:02:26 +0000 (10:02 -0800)]
scsi: lpfc: Fix PLOGI S_ID of 0 on pt2pt config
Under some pt2pt situations, the other end of the link may issue a LOGO
after successfully completing PLOGI and assigning addresses to the port.
Thus the driver may attempt a new PLOGI to re-create the login, but the
LOGO handling cleared the address back to 0. Once this happens, the other
end, which may be address 0, gets all confused and this cannot be resolved
without an administrative action to bounce the link.
Fix by assuming that address assignment only occurs on the 1st PLOGI after
link up, and regardless of login state, the address assignment sticks. The
FC standards aren't particularly clear in this situation (it only describes
initial PLOGI), but there is nothing that contradicts this and behaviors on
the devices tested appears to conform to the understanding.
Thus, don't reset the port address to 0 as part of LOGO handling. Port
addresses will only reset on link down.
Link: https://lore.kernel.org/r/20210104180240.46824-2-jsmart2021@gmail.com Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com> 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>
projects / thirdparty / linux.git / log
