Yixian Liu [Thu, 6 Feb 2020 09:56:44 +0000 (17:56 +0800)]
RDMA/hns: Add the workqueue framework for flush cqe handler
BugLink: https://launchpad.net/bugs/1864950
HiP08 RoCE hardware lacks ability(a known hardware problem) to flush
outstanding WQEs if QP state gets into errored mode for some reason. To
overcome this hardware problem and as a workaround, when QP is detected to
be in errored state during various legs like post send, post receive etc
[1], flush needs to be performed from the driver.
The earlier patch[1] sent to solve the hardware limitation explained in
the cover-letter had a bug in the software flushing leg. It acquired mutex
while modifying QP state to errored state and while conveying it to the
hardware using the mailbox. This caused leg to sleep while holding
spin-lock and caused crash.
Suggested Solution:
we have proposed to defer the flushing of the QP in the Errored state
using the workqueue to get around with the limitation of our hardware.
This patch adds the framework of the workqueue and the flush handler
function.
Xi Wang [Sun, 26 Jan 2020 14:58:35 +0000 (22:58 +0800)]
RDMA/hns: Optimize eqe buffer allocation flow
BugLink: https://launchpad.net/bugs/1864950
The eqe has a private multi-hop addressing implementation, but there is
already a set of interfaces in the hns driver that can achieve this.
So, simplify the eqe buffer allocation process by using the mtr interface
and remove large amount of repeated logic.
Yufeng Mo [Sat, 7 Mar 2020 03:42:50 +0000 (11:42 +0800)]
net: hns3: delete unnecessary logs after kzalloc fails
BugLink: https://launchpad.net/bugs/1867586
Since kernel already has logs after kzalloc fails,
it's unnecessary to print duplicate logs. So this
patch deletes these logs.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit fbdc4d79fcc2e226a36c9b8e2f1cdd80ca549094) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8de91e92070b5a083e4705cd4684c1802f7f730e) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yufeng Mo [Sat, 7 Mar 2020 03:42:48 +0000 (11:42 +0800)]
net: hns3: print out command code when dump fails in debugfs
BugLink: https://launchpad.net/bugs/1867586
This patch adds a local variable to save the command code in
some dump cases which need to modify the command code, then
the failing command code can be print out for debugging.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 77ba415d192011b5ef9e9979638772b42b5d4107) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Huazhong Tan [Sat, 7 Mar 2020 03:42:47 +0000 (11:42 +0800)]
net: hns3: print out status register when VF receives unknown source interrupt
BugLink: https://launchpad.net/bugs/1867586
When received an unknown vector 0 interrupt, there is not a
helpful information for user to realize that now. So this patch
prints out the value of the status register for this case, and
uses dev_info() instead of dev_dbg() in hclge_check_event_cause().
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit e45afb396e233b972aee187c7adb058859c5ac53) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yonglong Liu [Sat, 7 Mar 2020 03:42:46 +0000 (11:42 +0800)]
net: hns3: add a check before PF inform VF to reset
BugLink: https://launchpad.net/bugs/1867586
When setting VF's MAC from PF, if the VF driver not loaded, the
firmware will return error to PF.
So PF should check whether VF is alive before sending message to
VF when setting VF's MAC.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 9091367037d3e6db590d9f8cd9a163336665ef27) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Guojia Liao [Sat, 7 Mar 2020 03:42:45 +0000 (11:42 +0800)]
net: hns3: delete some reduandant code
BugLink: https://launchpad.net/bugs/1867586
In hclge_add_mc_addr_common() and hclge_rm_mc_addr_common(),
variable req had been set as "0" by memset(), so it's unnecessary
to set .entry_type field as "0" with hnae3_set_bit() again.
Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 01c45c521a5aa2e3a077b27d090f05a20012dd65) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yufeng Mo [Sat, 7 Mar 2020 03:42:44 +0000 (11:42 +0800)]
net: hns3: remove an unnecessary resetting check in hclge_handle_hw_ras_error()
BugLink: https://launchpad.net/bugs/1867586
In hclge_handle_hw_ras_error(), it is unnecessary to check
HCLGE_STATE_RST_HANDLING flag, because the reset priority
has been ensured by the process itself.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 89a85559302f473d2c7f22c774b31f979a0e62dc) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://launchpad.net/bugs/1867586
The name of macro HCLGE_MAX_NCL_CONFIG_LENGTH is inaccurate,
this patch renames it to HCLGE_NCL_CONFIG_LENGTH_IN_EACH_CMD.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4960cabff63e09066a8d02b0375b654d41ce174f) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Guojia Liao [Sat, 7 Mar 2020 03:42:42 +0000 (11:42 +0800)]
net: hns3: fix some mixed type assignment
BugLink: https://launchpad.net/bugs/1867586
This patch cleans up some incorrect type in assignment reported by sparse
and compiler.
The warning as below:
- warning : restricted __le16 degrades to integer
- warning : cast from restricted __le32
- warning : cast from restricted __be32
- warning : cast from restricted __be16
and "mixed operation".
Signed-off-by: Guojia Liao <liaoguojia@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 72fa490480ce5cd6a1b8ec741b369a470f93d61d) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yonglong Liu [Wed, 19 Feb 2020 01:23:33 +0000 (09:23 +0800)]
net: hns3: add missing help info for QS shaper in debugfs
BugLink: https://launchpad.net/bugs/1867586
HNS3 driver can dump QS shaper configs via debugfs, but missing
help info in debugfs for this operation.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 89ec9485282a3470217628fbabf34c789b475763) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yufeng Mo [Wed, 19 Feb 2020 01:23:32 +0000 (09:23 +0800)]
net: hns3: add support for dump MAC ID and loopback status in debugfs
BugLink: https://launchpad.net/bugs/1867586
The MAC ID and loopback status information are obtained from
the hardware, which will be helpful for debugging. This patch
adds support for these two items in debugfs.
Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit ded45d406ca736b3c23e7d099318465620fcd0f1) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Yonglong Liu [Wed, 19 Feb 2020 01:23:31 +0000 (09:23 +0800)]
net: hns3: add enabled TC numbers and DWRR weight info in debugfs
BugLink: https://launchpad.net/bugs/1867586
The actual enabled TC numbers and the DWRR weight of each
TC may be helpful for debugging, so adds them into debugfs.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a8adbb8a91a4cc260aeef7d670f3735b7b52865f) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Guangbin Huang [Wed, 19 Feb 2020 01:23:30 +0000 (09:23 +0800)]
net: hns3: modify an unsuitable print when setting unknown duplex to fibre
BugLink: https://launchpad.net/bugs/1867586
Currently, if device is in link down status and user uses
'ethtool -s' command to set speed but not specify duplex
mode, the duplex mode passed from ethtool to driver is
unknown value(255), and the fibre port will identify this
value as half duplex mode and print "only copper port
supports half duplex!". This message is confusing.
So for fibre port, only the setting duplex is half, prints
error and returns.
Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2d3db26d78805c9e06e26def0081c76e9bb0b7d6) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Aaron Ma [Tue, 7 Apr 2020 08:23:31 +0000 (16:23 +0800)]
UBUNTU: SAUCE: drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event
BugLink: https://bugs.launchpad.net/bugs/1871316
On ARCTURUS and RENOIR, powerplay is not supported yet.
When plug in or unplug power jack, ACPI event will issue.
Then kernel NULL pointer BUG will be triggered.
Check for NULL pointers before calling.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 170dbbf5ee571dbe11f847c27a15c6e28fdacfab
git://people.freedesktop.org/~agd5f/linux drm-next) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Bruno Meneguele [Tue, 7 Apr 2020 08:13:47 +0000 (10:13 +0200)]
net/bpfilter: remove superfluous testing message
A testing message was brought by 13d0f7b814d9 ("net/bpfilter: fix dprintf
usage for /dev/kmsg") but should've been deleted before patch submission.
Although it doesn't cause any harm to the code or functionality itself, it's
totally unpleasant to have it displayed on every loop iteration with no real
use case. Thus remove it unconditionally.
Fixes: 13d0f7b814d9 ("net/bpfilter: fix dprintf usage for /dev/kmsg") Signed-off-by: Bruno Meneguele <bmeneg@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 41c55ea6c2a7ca4c663eeec05bdf54f4e2419699) Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1871284
We've got quite a few bug reports showing the SOF driver being loaded
unintentionally recently, and the reason seems to be that users didn't
know the module option change: with the recent kernel, a new option
dsp_driver=1 has to be passed to a new module snd-intel-dspcfg
instead of snd_hda_intel.dmic_detect=0 option.
That is, actually there are two tricky things here:
- We changed the whole detection in another module and another
option semantics.
- The existing option for skipping the DSP probe was also renamed.
For avoiding the confusion and giving user more hint, this patch
reverts the renamed option dsp_driver back to dmic_detect for
snd-hda-intel module, and show the warning about the module option
change when the non-default value is passed.
BugLink: https://bugs.launchpad.net/bugs/1871284
Apply const prefix to the remaining possible places: the string
tables, the rate tables, the verb tables, the index tables, etc.
Just for minor optimization and no functional changes.
BugLink: https://bugs.launchpad.net/bugs/1871284
The recent addition of snd_intel_dsp_driver_probe() check caused a
spurious kernel warning when the driver is loaded for a non-Intel
hardware due to snd_BUG_ON(). Moreover, for such a hardware, we
should always return SND_INTEL_DSP_DRIVER_ANY, not check the
dsp_driver option at all.
This patch fixes these issues for non-Intel devices.
BugLink: https://bugs.launchpad.net/bugs/1871284
For distributions, we need one place where we can decide
which driver will be activated for the auto-configation of the
Intel's HDA hardware with DSP. Actually, we cover three drivers:
All those drivers registers similar PCI IDs, so the first
driver probed from the PCI stack can win. But... it is not
guaranteed that the correct driver wins.
This commit changes Intel's NHLT ACPI module to a common
DSP probe module for the Intel's hardware. All above sound
drivers calls this code. The user can force another behaviour
using the module parameter 'dsp_driver' located in
the 'snd-intel-dspcfg' module.
This change allows to add specific dmi checks for the specific
systems. The examples are taken from the pull request:
Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
we can reach max bytes/keys in key_alloc, but we forget to remove this
limit when we reserver space for payload in key_payload_reserve. So we
can only reach max keys but not max bytes when having delta between plen
and type->def_datalen. Remove this limit when instantiating the key, so we
can keep consistent with key_alloc.
Also, fix the similar problem in keyctl_chown_key().
Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys") Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly") Cc: stable@vger.kernel.org # 5.0.x Cc: Eric Biggers <ebiggers@google.com> Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
(cherry picked from commit 2e356101e72ab1361821b3af024d64877d9a798d) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: rtw88: Move driver IQK to set channel before association for 11N chip
BugLink: https://bugs.launchpad.net/bugs/1871300
Originally, driver do IQK after auth/assoc, but it's doing 4-way handshake
if we connect to an AP with WPA2 security. Since 11N chips use software IQK
that causes more than 100ms, so IQK and 4-way handshake can be overlap, then
4-way handshake may be failed. To resolve this issue, move IQK prior to
issue auth.
UBUNTU: SAUCE: rtw88: No retry and report for auth and assoc
BugLink: https://bugs.launchpad.net/bugs/1871300
The certain AP can't handle quick auth/assoc retry proerply, so disable
auth/assoc L2 retry and doesn't report TX status immediately, then wait for
cfg80211 connection retry that in period of 100ms.
Po-Hsu Lin [Mon, 6 Apr 2020 05:57:45 +0000 (13:57 +0800)]
selftests/powerpc: Turn off timeout setting for benchmarks, dscr, signal, tm
BugLink: https://bugs.launchpad.net/bugs/1864642
Some specific tests in powerpc can take longer than the default 45
seconds that added in commit 852c8cbf34d3 ("selftests/kselftest/runner.sh:
Add 45 second timeout per test") to run, the following test result was
collected across 2 Power8 nodes and 1 Power9 node in our pool:
powerpc/benchmarks/futex_bench - 52s
powerpc/dscr/dscr_sysfs_test - 116s
powerpc/signal/signal_fuzzer - 88s
powerpc/tm/tm_unavailable_test - 168s
powerpc/tm/tm-poison - 240s
Thus they will fail with TIMEOUT error. Disable the timeout setting
for these sub-tests to allow them finish properly.
https://bugs.launchpad.net/bugs/1864642 Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200318060004.10685-1-po-hsu.lin@canonical.com
(backported from commit 850507f30c38dff21ed557cb98ab16db26c32bbc)
[PHLin: fuzzy context adjustment] Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Prabhath Sajeepa [Mon, 28 Oct 2019 22:56:48 +0000 (16:56 -0600)]
nvme: Fix parsing of ANA log page
BugLink: https://bugs.launchpad.net/bugs/1856340
Check validity of offset into ANA log buffer before accessing
nvme_ana_group_desc. This check ensures the size of ANA log buffer >=
offset + sizeof(nvme_ana_group_desc)
Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Prabhath Sajeepa <psajeepa@purestorage.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 64fab7290dc3561729bbc1e35895a517eb2e549e) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Remove ambiguity and unconditionally clear the association_id if the
association has been terminated.
Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit bcde5f0fc7d318c98d4234b52bcc1a87fc2162d9) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 7db394848ece0e0706dfe8e4940b24e949f3b88f) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 44fbf3bb1ac3dbebc6bd07eb68abf2d0badfae65) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Tested interoperability with success:
- prior initiator with new target
- prior target with new initiator
- new on new
Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 53b2b2f59967c0b7eb4df265136b1cc25b9fb287) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Includes some minor mods where pre-release field names changed
by the time the spec was released.
Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit f16583614222d015968541f2e50447c67c277f74) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Mon, 10 Feb 2020 17:31:55 +0000 (09:31 -0800)]
scsi: lpfc: add RDF registration and Link Integrity FPIN logging
BugLink: https://bugs.launchpad.net/bugs/1855303
This patch modifies lpfc to register for Link Integrity events via the use
of an RDF ELS and to perform Link Integrity FPIN logging.
Specifically, the driver was modified to:
- Format and issue the RDF ELS immediately following SCR registration.
This registers the ability of the driver to receive FPIN ELS.
- Adds decoding of the FPIN els into the received descriptors, with
logging of the Link Integrity event information. After decoding, the ELS
is delivered to the scsi fc transport to be delivered to any user-space
applications.
- To aid in logging, simple helpers were added to create enum to name
string lookup functions that utilize the initialization helpers from the
fc_els.h header.
- Note: base header definitions for the ELS's don't populate the
descriptor payloads. As such, lpfc creates it's own version of the
structures, using the base definitions (mostly headers) and additionally
declaring the descriptors that will complete the population of the ELS.
Link: https://lore.kernel.org/r/20200210173155.547-3-jsmart2021@gmail.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>
(cherry picked from commit df3fe76658ed47617741819a501e2bd2ae446962 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
RDF is used to register for diagnostic events.
FPIN is how the fabric reports a diagnostic event.
Specifically, this patch:
- Adds the formal definition of TLV descriptors that are now used in a lot
of the FC spec. The simplistic fc_fn_desc structure, basically no more
than the tlv definition, is removed.
- Small tlv helper functions are added as defines.
- The list of known Descriptor tags (identifying the TLV) is expanded and
a name initializer introduced.
- The LSRI descriptor, returned in many new ELS response payloads is
added.
- The RDF ELS code is added, and the RDF request response structures
added.
- The FPIN els definition is corrected.
- A full definition of a Link Integrity Notification descriptor is added,
[mkp: rolled in kbuild warning fix]
Link: https://lore.kernel.org/r/20200210173155.547-2-jsmart2021@gmail.com Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 73ec6d2748dc35db2b32cf3c182a27c4a0837b9b linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 28 Jan 2020 00:23:09 +0000 (16:23 -0800)]
scsi: lpfc: Clean up hba max_lun_queue_depth checks
BugLink: https://bugs.launchpad.net/bugs/1855303
The current code does some odd +1 over maximum xri count checks and
requires that the lun_queue_count can't be bigger than maximum xri count
divided by 8. These items are bogus.
Clean the code up to cap lun_queue_count to maximum xri count.
James Smart [Tue, 28 Jan 2020 00:23:08 +0000 (16:23 -0800)]
scsi: lpfc: Remove handler for obsolete ELS - Read Port Status (RPS)
BugLink: https://bugs.launchpad.net/bugs/1855303
There was report of an odd "Fix me..." log message, which was tracked down
to the lpfc_els_rcv_rps() routine. This was in handling of a very old and
obsolete ELS - Read Port Status. The RPS ELS was defined in FC-LS-1, but
deprecated in FC-LS-2, and removed from all later FC-LS revisions. It was
replaced by the Read Diagnostic Parameters (RDP) ELS and the Link Error
Status Block descriptor.
There should be no support for the RSP ELS. Remove support from driver.
CID 15768 [Memory Corruption] Out-of-bounds access on FDMI
Sloppy coding of the fmdi structures. In both the lpfc_fdmi_attr_def and
lpfc_fdmi_reg_port_list structures, a field was placed at the start of
payload that may have variable content. The field was given an arbitrary
type (uint32_t). The code then uses the field name to derive an address,
which it used in things such as memset and memcpy. The memset sizes or
memcpy lengths were larger than the arbitrary type, thus coverity reported
an error.
Fix by replacing the arbitrary fields with the real field structures
describing the payload.
drivers/scsi/lpfc/lpfc_init.c: In function
‘lpfc_cpuhp_get_eq’: drivers/scsi/lpfc/lpfc_init.c:12660:1:
error: the frame size of 1032 bytes is larger than 1024 bytes
[-Werror=frame-larger-than=]
The issue is due to allocating a cpumask on the stack.
Fix by converting to a dynamical allocation of the cpu mask.
James Smart [Tue, 28 Jan 2020 00:23:05 +0000 (16:23 -0800)]
scsi: lpfc: Fix release of hwq to clear the eq relationship
BugLink: https://bugs.launchpad.net/bugs/1855303
When performing reset testing, the eq's list for related hwqs was getting
corrupted. In cases where there is not a 1:1 eq to hwq, the eq is
shared. The eq maintains a list of hwqs utilizing it in case of cpu
offlining and polling. During the reset, the hwqs are being torn down so
they can be recreated. The recreation was getting confused by seeing a
non-null eq assignment on the eq and the eq list became corrupt.
Correct by clearing the hdwq eq assignment when the hwq is cleaned up.
James Smart [Tue, 28 Jan 2020 00:23:03 +0000 (16:23 -0800)]
scsi: lpfc: Fix broken Credit Recovery after driver load
BugLink: https://bugs.launchpad.net/bugs/1855303
When driver is set to enable bb credit recovery, the switch displayed the
setting as inactive. If the link bounces, it switches to Active.
During link up processing, the driver currently does a MBX_READ_SPARAM
followed by a MBX_CONFIG_LINK. These mbox commands are queued to be
executed, one at a time and the completion is processed by the worker
thread. Since the MBX_READ_SPARAM is done BEFORE the MBX_CONFIG_LINK, the
BB_SC_N bit is never set the the returned values. BB Credit recovery status
only gets set after the driver requests the feature in CONFIG_LINK, which
is done after the link up. Thus the ordering of READ_SPARAM needs to follow
the CONFIG_LINK.
Fix by reordering so that READ_SPARAM is done after CONFIG_LINK. Added a
HBA_DEFER_FLOGI flag so that any FLOGI handling waits until after the
READ_SPARAM is done so that the proper BB credit value is set in the FLOGI
payload.
Fixes: 6bfb16208298 ("scsi: lpfc: Fix configuration of BB credit recovery in service parameters") Cc: <stable@vger.kernel.org> # v5.4+ Link: https://lore.kernel.org/r/20200128002312.16346-4-jsmart2021@gmail.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>
(cherry picked from commit 835214f5d5f516a38069bc077c879c7da00d6108 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 28 Jan 2020 00:23:02 +0000 (16:23 -0800)]
scsi: lpfc: Fix lpfc_io_buf resource leak in lpfc_get_scsi_buf_s4 error path
BugLink: https://bugs.launchpad.net/bugs/1855303
If a call to lpfc_get_cmd_rsp_buf_per_hdwq returns NULL (memory allocation
failure), a previously allocated lpfc_io_buf resource is leaked.
Fix by releasing the lpfc_io_buf resource in the failure path.
Fixes: d79c9e9d4b3d ("scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.") Cc: <stable@vger.kernel.org> # v5.4+ Link: https://lore.kernel.org/r/20200128002312.16346-3-jsmart2021@gmail.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>
(cherry picked from commit 0ab384a49c548baf132ccef249f78d9c6c506380 linux-next) Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Port Status Event: ... error 1=0x52004a01, error 2=0x218
The failure means an RQ timeout. That is, the adapter had received
asynchronous receive frames, ran out of buffer slots to place the frames,
and the driver did not replenish the buffer slots before a timeout
occurred. The driver should not be so slow in replenishing buffers that a
timeout can occur.
When the driver received all the frames of a sequence, it allocates an IOCB
to put the frames in. In a situation where there was no IOCB available for
the frame of a sequence, the RQ buffer corresponding to the first frame of
the sequence was not returned to the FW. Eventually, with enough traffic
encountering the situation, the timeout occurred.
Fix by releasing the buffer back to firmware whenever there is no IOCB for
the first frame.
Link: https://lore.kernel.org/r/20191218235808.31922-11-jsmart2021@gmail.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>
(cherry picked from commit 6d67e8473386e6133fd5d7ce0be887a7972672d6) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:58:07 +0000 (15:58 -0800)]
scsi: lpfc: Fix improper flag check for IO type
BugLink: https://bugs.launchpad.net/bugs/1855303
Current driver code looks at iocb types and uses a "==" comparison on the
flags to determine type. If another flag were set, it would disrupt the
comparison.
Fix by converting to a bitwise & operation.
Link: https://lore.kernel.org/r/20191218235808.31922-10-jsmart2021@gmail.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>
(cherry picked from commit c438d0628aa5cf9af57c7cd65794551622ea800d) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1855303
When running Cisco-MDS diagnostics which perform driver-level frame loop
back, the switch is reporting errors. Diagnostic has a limit on latency
that is not being met by the driver.
The requirement of Latency frames is that they should be responded back by
the host with a maximum delay of few hundreds of microseconds. If the
switch doesn't get response frames within this time frame, it fails the
test.
Test is failing as the lpfc-wq workqueue was overwhelmed by the packet rate
and in some cases, the work element yielded to other kernel elements.
To resolve, reduce the outstanding load allowed by the adapter. This
ensures the driver spends a reasonable amount of time doing loopback and
can do so such that latency values can be met. Load is managed by reducing
the number of receive buffers posted such that the link can be
backpressured to reduce load.
Link: https://lore.kernel.org/r/20191218235808.31922-9-jsmart2021@gmail.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>
(cherry picked from commit 999fbbceb8312a764b318cf19510273291ec3575) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:58:05 +0000 (15:58 -0800)]
scsi: lpfc: Fix unmap of dpp bars affecting next driver load
BugLink: https://bugs.launchpad.net/bugs/1855303
When unattaching, the driver did not unmap the DPP bar. This caused the
next load of the driver, which attempts to enable wc, to not work correctly
and wc to be disabled due to an address mapping overlap.
Fix by unmapping on unattach.
Link: https://lore.kernel.org/r/20191218235808.31922-8-jsmart2021@gmail.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>
(cherry picked from commit 0b4391946da872e825efa3edfa932e44ae6e9cf9) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:58:04 +0000 (15:58 -0800)]
scsi: lpfc: Fix disablement of FC-AL on lpe35000 models
BugLink: https://bugs.launchpad.net/bugs/1855303
The order of the flags/checks for adapters where FC-AL is supported
erroneously excluded lpe35000 adapter models. Also noted that the G7 flags
for Loop and Persistent topology are incorrect. They should follow the
rules as G6.
Rework the logic to enable LPe35000 FC-AL support. Collapse G7 support
logic to the same rules as G6.
Link: https://lore.kernel.org/r/20191218235808.31922-7-jsmart2021@gmail.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>
(cherry picked from commit a052ce848d4358c0094efc2c8f9aec0a31358e42) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:58:03 +0000 (15:58 -0800)]
scsi: lpfc: Fix ras_log via debugfs
BugLink: https://bugs.launchpad.net/bugs/1855303
/sys/kernel/debug/lpfc/fn0/ras_log always shows the same ras_log even if
there are link bounce events triggered via issue_lip
Dynamic FW logging had logic that prematurely breaks from the buffer
filling loop.
Fix the check for buffer overrun by looking before copying and restricting
copy length to the remaining buffer. When copying, ensure space for NULL
character is left in the buffer. While in the routine - ensure the buffer
is cleared before adding elements.
Link: https://lore.kernel.org/r/20191218235808.31922-6-jsmart2021@gmail.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>
(cherry picked from commit 9a20cc10fa0504693d2dadb90b2ae185755abc09) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:58:02 +0000 (15:58 -0800)]
scsi: lpfc: Fix Fabric hostname registration if system hostname changes
BugLink: https://bugs.launchpad.net/bugs/1855303
There are reports of multiple ports on the same system displaying different
hostnames in fabric FDMI displays.
Currently, the driver registers the hostname at initialization and obtains
the hostname via init_utsname()->nodename queried at the time the FC link
comes up. Unfortunately, if the machine hostname is updated after
initialization, such as via DHCP or admin command, the value registered
initially will be incorrect.
Fix by having the driver save the hostname that was registered with FDMI.
The driver then runs a heartbeat action that will check the hostname. If
the name changes, reregister the FMDI data.
The hostname is used in RSNN_NN, FDMI RPA and FDMI RHBA.
Link: https://lore.kernel.org/r/20191218235808.31922-5-jsmart2021@gmail.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>
(cherry picked from commit e3ba04c9bad1d1c7f15df43da25e878045150777) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:58:01 +0000 (15:58 -0800)]
scsi: lpfc: Fix missing check for CSF in Write Object Mbox Rsp
BugLink: https://bugs.launchpad.net/bugs/1855303
When the WriteObject mailbox response has change_status set to is 0x2
(Firmware Reset) or 0x04 (Port Migration Reset), the CSF field should also
be checked to see if a fw reset is sufficient to enable all new features in
the updated firmware image. If not, a fw reset would start the new
firmware, but with a feature level equal to existing firmware. To enable
the new features, a chip reset/pci slot reset would be required.
Check the CSF bit when change_status is 0x2 or 0x4 to know whether to
perform a pci bus reset or fw reset.
Link: https://lore.kernel.org/r/20191218235808.31922-4-jsmart2021@gmail.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>
(cherry picked from commit f3d0a8acc5a88435186d242376db05788a891516) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Wed, 18 Dec 2019 23:57:59 +0000 (15:57 -0800)]
scsi: lpfc: Fix incomplete NVME discovery when target
BugLink: https://bugs.launchpad.net/bugs/1855303
NVMe device re-discovery does not complete. Dev_loss_tmo messages seen on
initiator after recovery from a link disturbance.
The failing case is the following:
When the driver (as a NVME target) receives a PLOGI, the driver initiates
an "unreg rpi" mailbox command. While the mailbox command is in progress,
the driver requests that an ACC be sent to the initiator. The target's ACC
is received by the initiator and the initiator then transmits a PLOGI. The
driver receives the PLOGI prior to receiving the completion for the PLOGI
response WQE that sent the ACC. (Different delivery sources from the hw so
the race is very possible). Given the PLOGI is prior to the ACC completion
(signifying PLOGI exchange complete), the driver LS_RJT's the PRLI. The
"unreg rpi" mailbox then completes. Since PRLI has been received, the
driver transmits a PLOGI to restart discovery, which the initiator then
ACC's. If the driver processes the (re)PLOGI ACC prior to the completing
the handling for the earlier ACC it sent the intiators original PLOGI,
there is no state change for completion of the (re)PLOGI. The ndlp remains
in "PLOGI Sent" and the initiator continues sending PRLI's which are
rejected by the target until timeout or retry is reached.
Fix by: When in target mode, defer sending an ACC for the received PLOGI
until unreg RPI completes.
Link: https://lore.kernel.org/r/20191218235808.31922-2-jsmart2021@gmail.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>
(cherry picked from commit be0709e449ac9d9753a5c17e5b770d6e5e930e4a) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Thu, 21 Nov 2019 17:55:56 +0000 (09:55 -0800)]
scsi: lpfc: size cpu map by last cpu id set
BugLink: https://bugs.launchpad.net/bugs/1855303
Currently the lpfc driver sizes its cpu_map array based on
num_possible_cpus(). However, that can be a value that is less than the
highest cpu id bit that is set. As such, if a thread runs on a cpu with a
larger cpu id, or for_each_possible_cpu() is used, the driver could index
off the end of the array and return garbage or GPF.
The driver maintains its own internal copy of the "num_possible" cpu value
and sizes arrays by it.
Fix by setting the driver's value to the value of the last cpu id bit set
in the possible_mask - plus 1. Thus cpu_map will be sized to allow access
by any cpu id possible.
Link: https://lore.kernel.org/r/20191121175556.18953-1-jsmart2021@gmail.com Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit eede4970fb6c29f2056d7d016a3764c90e9d8a65) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20191111230401.12958-7-jsmart2021@gmail.com Reviewed-by: Ewan D. Milne <emilne@redhat.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>
(cherry picked from commit 3b294c0fb910dc91250abab574e85c9c1957c795) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Mon, 11 Nov 2019 23:04:00 +0000 (15:04 -0800)]
scsi: lpfc: revise nvme max queues to be hdwq count
BugLink: https://bugs.launchpad.net/bugs/1855303
Driver is setting the initiator nvme template with a max hw queues value of
the present cpu count which is odd. It should be registering the number of
hdwq queues (queues created on the adapter).
Change to set nvme tempate, in all cases, to the number of hardware queues.
Link: https://lore.kernel.org/r/20191111230401.12958-6-jsmart2021@gmail.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>
(cherry picked from commit 542ddc9b346984cb5bbc2a923d3f3f27ae961ffa) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Mon, 11 Nov 2019 23:03:59 +0000 (15:03 -0800)]
scsi: lpfc: Initialize cpu_map for not present cpus
BugLink: https://bugs.launchpad.net/bugs/1855303
Currently, cpu_map[cpu#]->hdwq is left to equal LPFC_VECTOR_MAP_EMPTY for
not present CPUs. If a CPU is dynamically hot-added, it is possible we may
crash due to not assigning an allocated hdwq.
Correct by assigning a hdwq at initialization for all not-present CPUs.
Fixes: dcaa21367938 ("scsi: lpfc: Change default IRQ model on AMD architectures") Link: https://lore.kernel.org/r/20191111230401.12958-5-jsmart2021@gmail.com Reviewed-by: Ewan D. Milne <emilne@redhat.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>
(cherry picked from commit bc227dde0d8b687aa525d01b0df5556d4d37eca3) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Fixes: 93a4d6f40198 ("scsi: lpfc: Add registration for CPU Offline/Online events") Link: https://lore.kernel.org/r/20191111230401.12958-4-jsmart2021@gmail.com Reviewed-by: Ewan D. Milne <emilne@redhat.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>
(cherry picked from commit d480e57809a043333a3b9e755c0bdd43e10a9f12) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Fixes: dcaa21367938 ("scsi: lpfc: Change default IRQ model on AMD architectures") Link: https://lore.kernel.org/r/20191108225947.1395-1-jsmart2021@gmail.com Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 61951a6d3153b4482404b739be921a7459f8dc12) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Possible unsafe locking scenario:
CPU0
----
lock(cpu_hotplug_lock.rw_sem);
lock(cpu_hotplug_lock.rw_sem);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by systemd-udevd/130:
#0: ffff8880d53fe210 (&dev->mutex){....}, at: __device_driver_lock+0x4a/0x70
#1: ffffffff826b05d0 (cpu_hotplug_lock.rw_sem){++++}, at: lpfc_sli4_enable_intr+0x422/0xd50 [lpfc]
Link: https://lore.kernel.org/r/20191105005708.7399-12-jsmart2021@gmail.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>
(cherry picked from commit aff6ab9e7221c1b5d15418419b9797e5badd4aec) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 5 Nov 2019 00:57:07 +0000 (16:57 -0800)]
scsi: lpfc: Add enablement of multiple adapter dumps
BugLink: https://bugs.launchpad.net/bugs/1855303
Some adapters support the ability to hold multiple adapter dumps on the
adapter flash. Some adapters default to enabling this feature while others
default to single-dump.
Make support uniform by enabling dual dump by default.
Link: https://lore.kernel.org/r/20191105005708.7399-11-jsmart2021@gmail.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>
(cherry picked from commit 171f6c41949f6e9d5e09dcac842a10bf8dda8dcc) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 5 Nov 2019 00:57:06 +0000 (16:57 -0800)]
scsi: lpfc: Change default IRQ model on AMD architectures
BugLink: https://bugs.launchpad.net/bugs/1855303
The current driver attempts to allocate an interrupt vector per cpu using
the systems managed IRQ allocator (flag PCI_IRQ_AFFINITY). The system IRQ
allocator will either provide the per-cpu vector, or return fewer
vectors. When fewer vectors, they are evenly spread between the numa nodes
on the system. When run on an AMD architecture, if interrupts occur to a
cpu that is not in the same numa node as the adapter generating the
interrupt, there are extreme costs and overheads in performance. Thus, if
1:1 vector allocation is used, or the "balanced" vectors in the other numa
nodes, performance can be hit significantly.
A much more performant model is to allocate interrupts only on the cpus
that are in the numa node where the adapter resides. I/O completion is
still performed by the cpu where the I/O was generated. Unfortunately,
there is no flag to request the managed IRQ subsystem allocate vectors only
for the CPUs in the numa node as the adapter.
On AMD architecture, revert the irq allocation to the normal style
(non-managed) and then use irq_set_affinity_hint() to set the cpu
affinity and disable user-space rebalancing.
Tie the support into CPU offline/online. If the cpu being offlined owns a
vector, the vector is re-affinitized to one of the other CPUs on the same
numa node. If there are no more CPUs on the numa node, the vector has all
affinity removed and lets the system determine where it's serviced.
Similarly, when the cpu that owned a vector comes online, the vector is
reaffinitized to the cpu.
Link: https://lore.kernel.org/r/20191105005708.7399-10-jsmart2021@gmail.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>
(cherry picked from commit dcaa213679387e95a315dca05c57dbb15273703c) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 5 Nov 2019 00:57:05 +0000 (16:57 -0800)]
scsi: lpfc: Add registration for CPU Offline/Online events
BugLink: https://bugs.launchpad.net/bugs/1855303
The recent affinitization didn't address cpu offlining/onlining. If an
interrupt vector is shared and the low order cpu owning the vector is
offlined, as interrupts are managed, the vector is taken offline. This
causes the other CPUs sharing the vector will hang as they can't get io
completions.
Correct by registering callbacks with the system for Offline/Online
events. When a cpu is taken offline, its eq, which is tied to an interrupt
vector is found. If the cpu is the "owner" of the vector and if the
eq/vector is shared by other CPUs, the eq is placed into a polled mode.
Additionally, code paths that perform io submission on the "sharing CPUs"
will check the eq state and poll for completion after submission of new io
to a wq that uses the eq.
Similarly, when a cpu comes back online and owns an offlined vector, the eq
is taken out of polled mode and rearmed to start driving interrupts for eq.
Link: https://lore.kernel.org/r/20191105005708.7399-9-jsmart2021@gmail.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>
(cherry picked from commit 93a4d6f40198dffcca35d9a928c409f9290f1fe0) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20191105005708.7399-8-jsmart2021@gmail.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>
(cherry picked from commit b9da814cd5f5bb93041a6e4dbc9c5149713186ff) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Revise the NVME PRLI checking to look for both inorder to enable SLER.
Link: https://lore.kernel.org/r/20191105005708.7399-7-jsmart2021@gmail.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>
(cherry picked from commit 69641627c653464db46f3e3d8c438349be055670) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 5 Nov 2019 00:57:00 +0000 (16:57 -0800)]
scsi: lpfc: Fix kernel crash at lpfc_nvme_info_show during remote port bounce
BugLink: https://bugs.launchpad.net/bugs/1855303
When reading sysfs nvme_info file while a remote port leaves and comes
back, a NULL pointer is encountered. The issue is due to ndlp list
corruption as the the nvme_info_show does not use the same lock as the rest
of the code.
Correct by removing the rcu_xxx_lock calls and replace by the host_lock and
phba->hbaLock spinlocks that are used by the rest of the driver. Given
we're called from sysfs, we are safe to use _irq rather than _irqsave.
Link: https://lore.kernel.org/r/20191105005708.7399-4-jsmart2021@gmail.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>
(cherry picked from commit 6c1e803eac846f886cd35131e6516fc51a8414b9) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Tue, 5 Nov 2019 00:56:59 +0000 (16:56 -0800)]
scsi: lpfc: Fix configuration of BB credit recovery in service parameters
BugLink: https://bugs.launchpad.net/bugs/1855303
The driver today is reading service parameters from the firmware and then
overwriting the firmware-provided values with values of its own. There are
some switch features that require preliminary FLOGI's that are
switch-specific and done prior to the actual fabric FLOGI for traffic. The
fw will perform those FLOGIs and will revise the service parameters for the
features configured. As the driver later overwrites those values with its
own values, it misconfigures things like BBSCN use by doing so.
Correct by eliminating the driver-overwrite of firmware values. The driver
correctly re-reads the service parameters after each link up to obtain the
latest values from firmware.
Link: https://lore.kernel.org/r/20191105005708.7399-3-jsmart2021@gmail.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>
(cherry picked from commit 6bfb1620829825c01e1dcdd63b6a7700352babd9) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
drivers/scsi/lpfc/lpfc_debugfs.c:2083:1: warning:
symbol 'lpfc_debugfs_ras_log_data' was not declared. Should it be static?
Link: https://lore.kernel.org/r/20191028132556.16272-1-yuehaibing@huawei.com Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: James Smart <james.smart@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 7b10db555257d1248398643a23e10cf36b50d516) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20191025184342.6623-1-jsmart2021@gmail.com Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 5792a0e81678da41f05bb724ebd20f134604fa15) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20191025182530.26653-1-jsmart2021@gmail.com Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 9e2edb41c3d4cab6da0eedcc07ae04758af62ab8) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20191018211832.7917-17-jsmart2021@gmail.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>
(cherry picked from commit 74acec655f560ef721c1e191732af2bcb094b537) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:31 +0000 (14:18 -0700)]
scsi: lpfc: Add additional discovery log messages
BugLink: https://bugs.launchpad.net/bugs/1855303
When debugging a recent discovery customer problem it was very hard to tell
what was happening with the existing discovery log messages. To fully debug
the issue additional log messages were necessary.
Add or extend log messages so that sufficient information is present for
debugging.
Link: https://lore.kernel.org/r/20191018211832.7917-16-jsmart2021@gmail.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>
(cherry picked from commit b4b3417cf6c8051f9f210cd694e6342fb008795c) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:30 +0000 (14:18 -0700)]
scsi: lpfc: Add FC-AL support to lpe32000 models
BugLink: https://bugs.launchpad.net/bugs/1855303
In the past, the lpe32000 models, based their main support being for 32G,
and as FC-AL is not supported in the FC standards past 8G, did not support
FC-AL operation.
This patch adds private-loop FC-AL support for the LPE32000 adapters
when a link is 8G or below. To avoid conditions where link rate may
change, which would cause non-connectivity to the AL device, FC-AL
mode must become a persistent setting and the link kept at a speed
supporting FC-AL.
The patch:
- Adds a pls attribute indicating whether the adapter properly supports
FC-AL.
- Adds support for the adapter to indicate that topology should be fixed
and the topology types to be configured.
- Adds a pt attribute to report the persistent topology if present.
Link: https://lore.kernel.org/r/20191018211832.7917-15-jsmart2021@gmail.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>
(cherry picked from commit 83c6cb1ae8be6948b5fa43b2450a176dba80688b) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20191018211832.7917-14-jsmart2021@gmail.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>
(cherry picked from commit e7d8595272553c27846946601b72e4c581f9712a) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Both macros print a message if the corresponding lpfc verbosity setting is
set or the kernel log level is WARNING or more critical.
One macro is for use with a phba structure, the other with a vport
structure.
[mkp: typo]
Link: https://lore.kernel.org/r/20191018211832.7917-13-jsmart2021@gmail.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>
(cherry picked from commit b1dfa5411ea440f7a5bd65176259ffb3bfbdecf0) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:27 +0000 (14:18 -0700)]
scsi: lpfc: Make FW logging dynamically configurable
BugLink: https://bugs.launchpad.net/bugs/1855303
Currently, the FW logging facility is a load/boot time parameter which
requires the driver to be unloaded/reloaded or the system rebooted in order
to change its configuration.
Convert the logging facility to allow dynamic enablement and configuration.
Specifically:
- Convert the feature so that it can be enabled dynamically via an
attribute. Additionally, the size of the buffer can be configured
dynamically.
- Add locks around states that now may be changing.
- Tie the feature into debugfs so that the logs can be read at any time.
Link: https://lore.kernel.org/r/20191018211832.7917-12-jsmart2021@gmail.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>
(cherry picked from commit 95bfc6d8ad86a76c89f62bb466f740b0fc05a667) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:26 +0000 (14:18 -0700)]
scsi: lpfc: Revise interrupt coalescing for missing scenarios
BugLink: https://bugs.launchpad.net/bugs/1855303
The existing "auto eq delay" mechanism was sometimes skipping over an EQ,
not ramping the coalescing down under light load fast enough, and in other
cases never kicked in as cpu sharing by multiple vectors didn't quite add
up right.
Tweak the interrupt mechanism such that:
- Add a flag to the EQ to force checking for colaescing values when being
serviced in the interrupt handler. The flag will be set by any CQ bound
to the EQ whenever the number of CQ elements process in a single scan
meets or exceeds the hardware queue notify level. E.g. there's a
significant number of completions happening.
- In the heartbeat work item that checks coalescing:
- Replace the structure that was counting the number of EQs that
interrupted on a single cpu with a new structure that looks at the EQ
to see whether EQ currently has a coalescing value (thus it should be
re-evaluate) or was marked by the new flag indicating heavy
completions.
- When a cpu, which may be servicing multiple vectors, had at least 1 EQ
that should be checked, a new coalescing delay is calculated based on
the number of interrupts that occurred on the cpu.
- The new coalescing value is then applied to the EQs that had
interrupted on the cpu.
Link: https://lore.kernel.org/r/20191018211832.7917-11-jsmart2021@gmail.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>
(cherry picked from commit 8156d378c4cbf8ca19df5d8f0c610ce6923b61e2) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1855303
Lower IOps performance with write operations. Perf tool shows lock
contention in dma_pool_alloc and dma_pool_free related to the
txrdy_payload_pool.
The allocations are for dma buffers for XFER_RDY's, which actually are not
needed for the FCP_TRECEIVE command as the command contents are used by the
adapter to generate the IU.
Remove the allocations and the associated buffer pool. Rather than leaving
NULLs in buffer pointer locations, set command and sgl to indicate skipped
SGLE indexes.
Link: https://lore.kernel.org/r/20191018211832.7917-10-jsmart2021@gmail.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>
(cherry picked from commit ea85a20cd54f3b09880f6c08994b059f0d114a11) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Added compiler unlikely hints to allow slightly better optimization of the
fast-path.
Removed a few pointer checks that were obviously already valid.
Link: https://lore.kernel.org/r/20191018211832.7917-9-jsmart2021@gmail.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>
(cherry picked from commit 22770cbabf6bb77a397d9f11d41f97667dd0caa2) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:19 +0000 (14:18 -0700)]
scsi: lpfc: Fix lockdep errors in sli_ringtx_put
BugLink: https://bugs.launchpad.net/bugs/1855303
Fix lockdep error in __lpfc_sli_ringtx_put(): The hbalock is valid for
sli3, but not for sli4. Change lockdep to look at ring lock if sli4.
Also update comment in __lpfc_sli_issue_iocb_s4() to reflect proper
lock. Note: lockdep check is already correct.
Link: https://lore.kernel.org/r/20191018211832.7917-4-jsmart2021@gmail.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>
(cherry picked from commit 27f3efd637ce4859a44a7ca730c72392b4111c26) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:18 +0000 (14:18 -0700)]
scsi: lpfc: Fix reporting of read-only fw error errors
BugLink: https://bugs.launchpad.net/bugs/1855303
When the adapter FW is administratively set to RO mode, a FW update
triggered by the driver's sysfs attribute will fail. Currently, the
driver's logging mechanism does not properly parse the adapter return codes
and print a meaningful message. This oversight prevents quick diagnosis in
the field.
Parse the adapter return codes for Write_Object and write an appropriate
message to the system console.
[mkp: typo]
Link: https://lore.kernel.org/r/20191018211832.7917-3-jsmart2021@gmail.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>
(cherry picked from commit 0a5ce731977da1cc6d8d6d7df01c2e53ebb81796) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Fri, 18 Oct 2019 21:18:17 +0000 (14:18 -0700)]
scsi: lpfc: fix lpfc_nvmet_mrq to be bound by hdw queue count
BugLink: https://bugs.launchpad.net/bugs/1855303
Currently, lpfc_nvmet_mrq is always scaled back to the min(lpfc_nvmet_mrq,
lpfc_irq_chann). There's no reason to reduce it to the number of interrupt
vectors. Rather, it should be scaled down based on the number of hardware
queues for the system (if lower than max of 16).
Change scaling to use hardware queue count rather than interrupt vector
count.
Link: https://lore.kernel.org/r/20191018211832.7917-2-jsmart2021@gmail.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>
(cherry picked from commit 97a9ed3b3ae8eae27a231129c0939151879d5f2b) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
drivers/scsi/lpfc/lpfc_nportdisc.c:290:1: warning: symbol 'lpfc_defer_pt2pt_acc' was not declared. Should it be static?
Link: https://lore.kernel.org/r/1570183477-137273-1-git-send-email-zhengbin13@huawei.com Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Reviewed-by: Dick Kennedy <dick.kennedy@broadcom.com> Reviewed-by: James Smart <james.smart@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit f7cb0d0945ebc9879aff72cf7b3342fd1040ffaa) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Link: https://lore.kernel.org/r/20190922035906.10977-21-jsmart2021@gmail.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>
(cherry picked from commit 5f9d423a725a86505ba42ed026c9a827410a69cd) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Presumed residual (or unused) code from previous commit.
Removed fcp_txcmplq_cnt.
Link: https://lore.kernel.org/r/20190922035906.10977-20-jsmart2021@gmail.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>
(cherry picked from commit ff349bca17716f310697b619b8cf9b926e852ba9) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
James Smart [Sun, 22 Sep 2019 03:59:04 +0000 (20:59 -0700)]
scsi: lpfc: Complete removal of FCoE T10 PI support on SLI-4 adapters
BugLink: https://bugs.launchpad.net/bugs/1855303
T10 PI support on SLI-4-based FCoE adapters is not supported. A prior
commit in the 12.4.0.0 stream added device recognition that would prevent
T10 PI enablement. However, it didn't contain a complete device list. Thus
some SLI-4 FCoE adapters still had T10 PI enabled.
Fix by expanding the device list that identifies FCoE devices.
Link: https://lore.kernel.org/r/20190922035906.10977-19-jsmart2021@gmail.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>
(cherry picked from commit 412e7375e48fc7dc660da99c4b699e4475873f7b) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
- an EEPROM failure error reported by the adapter.
- ensures that all data for any ACQE, recognized or not, is logged.
- Given that all data is now logged unconditionally, the default case
(unrecognized) data can be reduced.
Link: https://lore.kernel.org/r/20190922035906.10977-18-jsmart2021@gmail.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>
(cherry picked from commit d11ed16db698c31663938d004451b11ac6b2b2e1) Signed-off-by: Vignesh Gunasekaran <vignesh.gunasekaran@broadcom.com> Signed-off-by: Jeff Lane <jeffrey.lane@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>