April 2024 - Linux-stable-mirror

[PATCH v2] phy: freescale: imx8m-pcie: fix pcie link-up instability

by Marcel Ziswiler

From: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> On the i.MX 8M Mini, the AUX_PLL_REFCLK_SEL has to be left at its reset default of AUX_IN (PLL clock). Background Information: In our automated testing setup, we use Delock Mini-PCIe SATA cards [1]. While this setup has proven very stable overall we noticed upstream on the i.MX 8M Mini fails quite regularly (about 50/50) to bring up the PCIe link while with NXP's downstream BSP 5.15.71_2.2.2 it always works. As that old downstream stuff was quite different, I first also tried NXP's latest downstream BSP 6.1.55_2.2.0 which from a PCIe point of view is fairly vanilla, however, also there the PCIe link-up was not stable. Comparing and debugging I noticed that upstream explicitly configures the AUX_PLL_REFCLK_SEL to I_PLL_REFCLK_FROM_SYSPLL while working downstream [2] leaving it at reset defaults of AUX_IN (PLL clock). Unfortunately, the TRM does not mention any further details about this register (both for the i.MX 8M Mini as well as the Plus). NXP confirmed their validation codes for the i.MX8MM PCIe doesn't configure cmn_reg063 (offset: 0x18C). BTW: On the i.MX 8M Plus we have not seen any issues with PCIe with the exact same setup which is why I left it unchanged. [1] https://www.delock.com/produkt/95233/merkmale.html [2] https://github.com/nxp-imx/linux-imx/blob/lf-5.15.71-2.2.0/drivers/pci/cont… Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Cc: stable(a)vger.kernel.org # 6.1.x: ca679c49: phy: freescale: imx8m-pcie: Refine i.MX8MM PCIe PHY driver Cc: stable(a)vger.kernel.org # 6.1.x Signed-off-by: Marcel Ziswiler <marcel.ziswiler(a)toradex.com> Reviewed-by: Richard Zhu <hongxing.zhu(a)nxp.com> Link: https://lore.kernel.org/all/AS8PR04MB867661386FEA07649771FBE18C362@AS8PR04M… --- Changes in v2: - Reword the commmit message. - Meld the background information from the cover letter into the commit message as suggested by Fabio. Thanks! - Document NXP's confirmation from their validation codes and add Richard Zhu's reviewed-by. Thanks! drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c index b700f52b7b67..11fcb1867118 100644 --- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c +++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c @@ -110,8 +110,10 @@ static int imx8_pcie_phy_power_on(struct phy *phy) /* Source clock from SoC internal PLL */ writel(ANA_PLL_CLK_OUT_TO_EXT_IO_SEL, imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG062); - writel(AUX_PLL_REFCLK_SEL_SYS_PLL, - imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063); + if (imx8_phy->drvdata->variant != IMX8MM) { + writel(AUX_PLL_REFCLK_SEL_SYS_PLL, + imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG063); + } val = ANA_AUX_RX_TX_SEL_TX | ANA_AUX_TX_TERM; writel(val | ANA_AUX_RX_TERM_GND_EN, imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG064); -- 2.44.0

9 months

3
3
0 0

[PATCH v3] rust: make mutually exclusive with CFI_CLANG

by Conor Dooley

From: Conor Dooley <conor.dooley(a)microchip.com> On RISC-V and arm64, and presumably x86, if CFI_CLANG is enabled, loading a rust module will trigger a kernel panic. Support for sanitisers, including kcfi (CFI_CLANG), is in the works, but for now they're nightly-only options in rustc. Make RUST depend on !CFI_CLANG to prevent configuring a kernel without symmetrical support for kfi. Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") cc: stable(a)vger.kernel.org Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> --- Sending this one on its own, there's no explicit dep on this for the riscv enabling patch, v3 to continue the numbering from there. Nothing has changed since v2. CC: Miguel Ojeda <ojeda(a)kernel.org> CC: Alex Gaynor <alex.gaynor(a)gmail.com> CC: Wedson Almeida Filho <wedsonaf(a)gmail.com> CC: linux-kernel(a)vger.kernel.org (open list) CC: rust-for-linux(a)vger.kernel.org CC: Sami Tolvanen <samitolvanen(a)google.com> CC: Kees Cook <keescook(a)chromium.org> CC: Nathan Chancellor <nathan(a)kernel.org> CC: llvm(a)lists.linux.dev --- init/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/init/Kconfig b/init/Kconfig index aa02aec6aa7d..ad9a2da27dc9 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1899,6 +1899,7 @@ config RUST bool "Rust support" depends on HAVE_RUST depends on RUST_IS_AVAILABLE + depends on !CFI_CLANG depends on !MODVERSIONS depends on !GCC_PLUGINS depends on !RANDSTRUCT -- 2.43.0

9 months

5
8
0 0

[PATCH v4] rust: init: remove impl Zeroable for Infallible

by Laine Taffin Altman

In Rust, producing an invalid value of any type is immediate undefined behavior (UB); this includes via zeroing memory. Therefore, since an uninhabited type has no valid values, producing any values at all for it is UB. The Rust standard library type `core::convert::Infallible` is uninhabited, by virtue of having been declared as an enum with no cases, which always produces uninhabited types in Rust. The current kernel code allows this UB to be triggered, for example by code like `Box::<core::convert::Infallible>::init(kernel::init::zeroed())`. Thus, remove the implementation of `Zeroable` for `Infallible`, thereby avoiding the unsoundness (potential for future UB). Cc: stable(a)vger.kernel.org Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") Closes: https://github.com/Rust-for-Linux/pinned-init/pull/13 Signed-off-by: Laine Taffin Altman <alexanderaltman(a)me.com> Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Reviewed-by: Boqun Feng <boqun.feng(a)gmail.com> --- V3 -> V4: Address review nits; run checkpatch properly. V2 -> V3: Email formatting correction. V1 -> V2: Added more documentation to the comment, with links; also added more details to the commit message. rust/kernel/init.rs | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs index 424257284d16..3859c7ff81b7 100644 --- a/rust/kernel/init.rs +++ b/rust/kernel/init.rs @@ -1292,8 +1292,15 @@ macro_rules! impl_zeroable { i8, i16, i32, i64, i128, isize, f32, f64, - // SAFETY: These are ZSTs, there is nothing to zero. - {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, Infallible, (), + // Note: do not add uninhabited types (such as `!` or `core::convert::Infallible`) to this list; + // creating an instance of an uninhabited type is immediate undefined behavior. For more on + // uninhabited/empty types, consult The Rustonomicon: + // https://doc.rust-lang.org/stable/nomicon/exotic-sizes.html#empty-types The Rust Reference + // also has information on undefined behavior: + // https://doc.rust-lang.org/stable/reference/behavior-considered-undefined.ht… + // + // SAFETY: These are inhabited ZSTs; there is nothing to zero and a valid value exists. + {<T: ?Sized>} PhantomData<T>, core::marker::PhantomPinned, (), // SAFETY: Type is allowed to take any value, including all zeros. {<T>} MaybeUninit<T>, base-commit: c85af715cac0a951eea97393378e84bb49384734 -- 2.44.0

9 months

3
6
0 0

Re: Patch "usb: typec: ucsi: Check for notifications after init" has been added to the 6.8-stable tree

by Christian Ehrhardt

Hi Sasha, On Sun, Apr 07, 2024 at 08:53:40AM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > usb: typec: ucsi: Check for notifications after init > > to the 6.8-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… This patch contains an out of bounds memory access and should not be included in the stable backports until a fix is available. A fix is already queued in Greg's usb-linus branch. Please drop the above patch from all stable trees for now. Sorry for the inconvenience. > The filename of the patch is: > usb-typec-ucsi-check-for-notifications-after-init.patch > and it can be found in the queue-6.8 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 903bfed719f3e87b607956bbe4d855c71831a43a > Author: Christian A. Ehrhardt <lk(a)c--e.de> > Date: Wed Mar 20 08:39:23 2024 +0100 > > usb: typec: ucsi: Check for notifications after init > > [ Upstream commit 808a8b9e0b87bbc72bcc1f7ddfe5d04746e7ce56 ] > > The completion notification for the final SET_NOTIFICATION_ENABLE > command during initialization can include a connector change > notification. However, at the time this completion notification is > processed, the ucsi struct is not ready to handle this notification. > As a result the notification is ignored and the controller > never sends an interrupt again. > > Re-check CCI for a pending connector state change after > initialization is complete. Adjust the corresponding debug > message accordingly. > > Fixes: 71a1fa0df2a3 ("usb: typec: ucsi: Store the notification mask") > Cc: stable(a)vger.kernel.org > Signed-off-by: Christian A. Ehrhardt <lk(a)c--e.de> > Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> > Tested-by: Neil Armstrong <neil.armstrong(a)linaro.org> # on SM8550-QRD > Link: https://lore.kernel.org/r/20240320073927.1641788-3-lk@c--e.de > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c > index 0bfe5e906e543..96da828f556a9 100644 > --- a/drivers/usb/typec/ucsi/ucsi.c > +++ b/drivers/usb/typec/ucsi/ucsi.c > @@ -962,7 +962,7 @@ void ucsi_connector_change(struct ucsi *ucsi, u8 num) > struct ucsi_connector *con = &ucsi->connector[num - 1]; > > if (!(ucsi->ntfy & UCSI_ENABLE_NTFY_CONNECTOR_CHANGE)) { > - dev_dbg(ucsi->dev, "Bogus connector change event\n"); > + dev_dbg(ucsi->dev, "Early connector change event\n"); > return; > } > > @@ -1393,6 +1393,7 @@ static int ucsi_init(struct ucsi *ucsi) > { > struct ucsi_connector *con, *connector; > u64 command, ntfy; > + u32 cci; > int ret; > int i; > > @@ -1445,6 +1446,13 @@ static int ucsi_init(struct ucsi *ucsi) > > ucsi->connector = connector; > ucsi->ntfy = ntfy; > + > + ret = ucsi->ops->read(ucsi, UCSI_CCI, &cci, sizeof(cci)); > + if (ret) > + return ret; > + if (UCSI_CCI_CONNECTOR(READ_ONCE(cci))) > + ucsi_connector_change(ucsi, cci); > + > return 0; > > err_unregister: > Best regards Christian

9 months

1
0
0 0

[PATCH 0/3] dmaengine: xilinx: xdma: Various fixes for xdma

by Louis Chauvet

The current driver have some issues, this series fixes them. PATCH 1 is fixing a wrong offset computation in the dma descriptor address PATCH 2 is fixing the xdma_synchronize callback, which was not waiting properly for the last transfer. PATCH 3 is clarifing the documentation for xdma_fill_descs --- Louis Chauvet (1): dmaengine: xilinx: xdma: Fix synchronization issue Miquel Raynal (2): dmaengine: xilinx: xdma: Fix wrong offsets in the buffers addresses in dma descriptor dmaengine: xilinx: xdma: Clarify kdoc in XDMA driver drivers/dma/xilinx/xdma-regs.h | 3 +++ drivers/dma/xilinx/xdma.c | 42 +++++++++++++++++++++++++++--------------- 2 files changed, 30 insertions(+), 15 deletions(-) --- base-commit: 8e938e39866920ddc266898e6ae1fffc5c8f51aa change-id: 20240322-digigram-xdma-fixes-aa13451b7474 Best regards, -- Louis Chauvet <louis.chauvet(a)bootlin.com>

9 months

5
9
0 0

[PATCH net v4] virtio_net: Do not send RSS key if it is not supported

by Breno Leitao

There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device. Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") Cc: stable(a)vger.kernel.org Cc: qemu-devel(a)nongnu.org Signed-off-by: Breno Leitao <leitao(a)debian.org> Reviewed-by: Heng Qi <hengqi(a)linux.alibaba.com> --- Changelog: V2: * Moved from creating a valid packet, by rejecting the request completely. V3: * Got some good feedback from and Xuan Zhuo and Heng Qi, and reworked the rejection path. V4: * Added a comment in an "if" clause, as suggested by Michael S. Tsirkin. --- drivers/net/virtio_net.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index c22d1118a133..115c3c5414f2 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -3807,6 +3807,7 @@ static int virtnet_set_rxfh(struct net_device *dev, struct netlink_ext_ack *extack) { struct virtnet_info *vi = netdev_priv(dev); + bool update = false; int i; if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE && @@ -3814,13 +3815,28 @@ static int virtnet_set_rxfh(struct net_device *dev, return -EOPNOTSUPP; if (rxfh->indir) { + if (!vi->has_rss) + return -EOPNOTSUPP; + for (i = 0; i < vi->rss_indir_table_size; ++i) vi->ctrl->rss.indirection_table[i] = rxfh->indir[i]; + update = true; } - if (rxfh->key) + + if (rxfh->key) { + /* If either _F_HASH_REPORT or _F_RSS are negotiated, the + * device provides hash calculation capabilities, that is, + * hash_key is configured. + */ + if (!vi->has_rss && !vi->has_rss_hash_report) + return -EOPNOTSUPP; + memcpy(vi->ctrl->rss.key, rxfh->key, vi->rss_key_size); + update = true; + } - virtnet_commit_rss_command(vi); + if (update) + virtnet_commit_rss_command(vi); return 0; } @@ -4729,13 +4745,15 @@ static int virtnet_probe(struct virtio_device *vdev) if (virtio_has_feature(vdev, VIRTIO_NET_F_HASH_REPORT)) vi->has_rss_hash_report = true; - if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS)) + if (virtio_has_feature(vdev, VIRTIO_NET_F_RSS)) { vi->has_rss = true; - if (vi->has_rss || vi->has_rss_hash_report) { vi->rss_indir_table_size = virtio_cread16(vdev, offsetof(struct virtio_net_config, rss_max_indirection_table_length)); + } + + if (vi->has_rss || vi->has_rss_hash_report) { vi->rss_key_size = virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size)); -- 2.43.0

9 months

3
2
0 0

[PATCH AUTOSEL 4.19 1/5] scsi: lpfc: Update lpfc_ramp_down_queue_handler() logic

by Sasha Levin

From: Justin Tee <justin.tee(a)broadcom.com> [ Upstream commit bb011631435c705cdeddca68d5c85fd40a4320f9 ] Typically when an out of resource CQE status is detected, the lpfc_ramp_down_queue_handler() logic is called to help reduce I/O load by reducing an sdev's queue_depth. However, the current lpfc_rampdown_queue_depth() logic does not help reduce queue_depth. num_cmd_success is never updated and is always zero, which means new_queue_depth will always be set to sdev->queue_depth. So, new_queue_depth = sdev->queue_depth - new_queue_depth always sets new_queue_depth to zero. And, scsi_change_queue_depth(sdev, 0) is essentially a no-op. Change the lpfc_ramp_down_queue_handler() logic to set new_queue_depth equal to sdev->queue_depth subtracted from number of times num_rsrc_err was incremented. If num_rsrc_err is >= sdev->queue_depth, then set new_queue_depth equal to 1. Eventually, the frequency of Good_Status frames will signal SCSI upper layer to auto increase the queue_depth back to the driver default of 64 via scsi_handle_queue_ramp_up(). Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-5-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/scsi/lpfc/lpfc.h | 1 - drivers/scsi/lpfc/lpfc_scsi.c | 13 ++++--------- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index 53b661793268f..5698928d8029c 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -989,7 +989,6 @@ struct lpfc_hba { unsigned long bit_flags; #define FABRIC_COMANDS_BLOCKED 0 atomic_t num_rsrc_err; - atomic_t num_cmd_success; unsigned long last_rsrc_error_time; unsigned long last_ramp_down_time; #ifdef CONFIG_SCSI_LPFC_DEBUG_FS diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index 425b83618a2e5..02d067e1fc45c 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c @@ -303,11 +303,10 @@ lpfc_ramp_down_queue_handler(struct lpfc_hba *phba) struct Scsi_Host *shost; struct scsi_device *sdev; unsigned long new_queue_depth; - unsigned long num_rsrc_err, num_cmd_success; + unsigned long num_rsrc_err; int i; num_rsrc_err = atomic_read(&phba->num_rsrc_err); - num_cmd_success = atomic_read(&phba->num_cmd_success); /* * The error and success command counters are global per @@ -322,20 +321,16 @@ lpfc_ramp_down_queue_handler(struct lpfc_hba *phba) for (i = 0; i <= phba->max_vports && vports[i] != NULL; i++) { shost = lpfc_shost_from_vport(vports[i]); shost_for_each_device(sdev, shost) { - new_queue_depth = - sdev->queue_depth * num_rsrc_err / - (num_rsrc_err + num_cmd_success); - if (!new_queue_depth) - new_queue_depth = sdev->queue_depth - 1; + if (num_rsrc_err >= sdev->queue_depth) + new_queue_depth = 1; else new_queue_depth = sdev->queue_depth - - new_queue_depth; + num_rsrc_err; scsi_change_queue_depth(sdev, new_queue_depth); } } lpfc_destroy_vport_work_array(phba, vports); atomic_set(&phba->num_rsrc_err, 0); - atomic_set(&phba->num_cmd_success, 0); } /** -- 2.43.0

9 months

1
4
0 0

[PATCH AUTOSEL 5.4 1/6] scsi: lpfc: Update lpfc_ramp_down_queue_handler() logic

by Sasha Levin

From: Justin Tee <justin.tee(a)broadcom.com> [ Upstream commit bb011631435c705cdeddca68d5c85fd40a4320f9 ] Typically when an out of resource CQE status is detected, the lpfc_ramp_down_queue_handler() logic is called to help reduce I/O load by reducing an sdev's queue_depth. However, the current lpfc_rampdown_queue_depth() logic does not help reduce queue_depth. num_cmd_success is never updated and is always zero, which means new_queue_depth will always be set to sdev->queue_depth. So, new_queue_depth = sdev->queue_depth - new_queue_depth always sets new_queue_depth to zero. And, scsi_change_queue_depth(sdev, 0) is essentially a no-op. Change the lpfc_ramp_down_queue_handler() logic to set new_queue_depth equal to sdev->queue_depth subtracted from number of times num_rsrc_err was incremented. If num_rsrc_err is >= sdev->queue_depth, then set new_queue_depth equal to 1. Eventually, the frequency of Good_Status frames will signal SCSI upper layer to auto increase the queue_depth back to the driver default of 64 via scsi_handle_queue_ramp_up(). Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-5-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/scsi/lpfc/lpfc.h | 1 - drivers/scsi/lpfc/lpfc_scsi.c | 13 ++++--------- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index 7ce0d94cdc018..98ab07c3774ed 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -1039,7 +1039,6 @@ struct lpfc_hba { unsigned long bit_flags; #define FABRIC_COMANDS_BLOCKED 0 atomic_t num_rsrc_err; - atomic_t num_cmd_success; unsigned long last_rsrc_error_time; unsigned long last_ramp_down_time; #ifdef CONFIG_SCSI_LPFC_DEBUG_FS diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index 816235ccd2992..f238e0f41f07c 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c @@ -246,11 +246,10 @@ lpfc_ramp_down_queue_handler(struct lpfc_hba *phba) struct Scsi_Host *shost; struct scsi_device *sdev; unsigned long new_queue_depth; - unsigned long num_rsrc_err, num_cmd_success; + unsigned long num_rsrc_err; int i; num_rsrc_err = atomic_read(&phba->num_rsrc_err); - num_cmd_success = atomic_read(&phba->num_cmd_success); /* * The error and success command counters are global per @@ -265,20 +264,16 @@ lpfc_ramp_down_queue_handler(struct lpfc_hba *phba) for (i = 0; i <= phba->max_vports && vports[i] != NULL; i++) { shost = lpfc_shost_from_vport(vports[i]); shost_for_each_device(sdev, shost) { - new_queue_depth = - sdev->queue_depth * num_rsrc_err / - (num_rsrc_err + num_cmd_success); - if (!new_queue_depth) - new_queue_depth = sdev->queue_depth - 1; + if (num_rsrc_err >= sdev->queue_depth) + new_queue_depth = 1; else new_queue_depth = sdev->queue_depth - - new_queue_depth; + num_rsrc_err; scsi_change_queue_depth(sdev, new_queue_depth); } } lpfc_destroy_vport_work_array(phba, vports); atomic_set(&phba->num_rsrc_err, 0); - atomic_set(&phba->num_cmd_success, 0); } /** -- 2.43.0

9 months

1
5
0 0

[PATCH AUTOSEL 5.10 1/7] scsi: lpfc: Update lpfc_ramp_down_queue_handler() logic

by Sasha Levin

From: Justin Tee <justin.tee(a)broadcom.com> [ Upstream commit bb011631435c705cdeddca68d5c85fd40a4320f9 ] Typically when an out of resource CQE status is detected, the lpfc_ramp_down_queue_handler() logic is called to help reduce I/O load by reducing an sdev's queue_depth. However, the current lpfc_rampdown_queue_depth() logic does not help reduce queue_depth. num_cmd_success is never updated and is always zero, which means new_queue_depth will always be set to sdev->queue_depth. So, new_queue_depth = sdev->queue_depth - new_queue_depth always sets new_queue_depth to zero. And, scsi_change_queue_depth(sdev, 0) is essentially a no-op. Change the lpfc_ramp_down_queue_handler() logic to set new_queue_depth equal to sdev->queue_depth subtracted from number of times num_rsrc_err was incremented. If num_rsrc_err is >= sdev->queue_depth, then set new_queue_depth equal to 1. Eventually, the frequency of Good_Status frames will signal SCSI upper layer to auto increase the queue_depth back to the driver default of 64 via scsi_handle_queue_ramp_up(). Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-5-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/scsi/lpfc/lpfc.h | 1 - drivers/scsi/lpfc/lpfc_scsi.c | 13 ++++--------- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index cf69f831a7253..8f1b5b0ee8cd8 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -1065,7 +1065,6 @@ struct lpfc_hba { unsigned long bit_flags; #define FABRIC_COMANDS_BLOCKED 0 atomic_t num_rsrc_err; - atomic_t num_cmd_success; unsigned long last_rsrc_error_time; unsigned long last_ramp_down_time; #ifdef CONFIG_SCSI_LPFC_DEBUG_FS diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index b4b87e5d8b291..2121534838747 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c @@ -246,11 +246,10 @@ lpfc_ramp_down_queue_handler(struct lpfc_hba *phba) struct Scsi_Host *shost; struct scsi_device *sdev; unsigned long new_queue_depth; - unsigned long num_rsrc_err, num_cmd_success; + unsigned long num_rsrc_err; int i; num_rsrc_err = atomic_read(&phba->num_rsrc_err); - num_cmd_success = atomic_read(&phba->num_cmd_success); /* * The error and success command counters are global per @@ -265,20 +264,16 @@ lpfc_ramp_down_queue_handler(struct lpfc_hba *phba) for (i = 0; i <= phba->max_vports && vports[i] != NULL; i++) { shost = lpfc_shost_from_vport(vports[i]); shost_for_each_device(sdev, shost) { - new_queue_depth = - sdev->queue_depth * num_rsrc_err / - (num_rsrc_err + num_cmd_success); - if (!new_queue_depth) - new_queue_depth = sdev->queue_depth - 1; + if (num_rsrc_err >= sdev->queue_depth) + new_queue_depth = 1; else new_queue_depth = sdev->queue_depth - - new_queue_depth; + num_rsrc_err; scsi_change_queue_depth(sdev, new_queue_depth); } } lpfc_destroy_vport_work_array(phba, vports); atomic_set(&phba->num_rsrc_err, 0); - atomic_set(&phba->num_cmd_success, 0); } /** -- 2.43.0

9 months

1
6
0 0

[PATCH AUTOSEL 5.15 01/10] scsi: lpfc: Move NPIV's transport unregistration to after resource clean up

by Sasha Levin

From: Justin Tee <justin.tee(a)broadcom.com> [ Upstream commit 4ddf01f2f1504fa08b766e8cfeec558e9f8eef6c ] There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent. Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Link: https://lore.kernel.org/r/20240305200503.57317-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/scsi/lpfc/lpfc_vport.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_vport.c b/drivers/scsi/lpfc/lpfc_vport.c index da9a1f72d9383..b1071226e27fb 100644 --- a/drivers/scsi/lpfc/lpfc_vport.c +++ b/drivers/scsi/lpfc/lpfc_vport.c @@ -651,10 +651,6 @@ lpfc_vport_delete(struct fc_vport *fc_vport) lpfc_free_sysfs_attr(vport); lpfc_debugfs_terminate(vport); - /* Remove FC host to break driver binding. */ - fc_remove_host(shost); - scsi_remove_host(shost); - /* Send the DA_ID and Fabric LOGO to cleanup Nameserver entries. */ ndlp = lpfc_findnode_did(vport, Fabric_DID); if (!ndlp) @@ -700,6 +696,10 @@ lpfc_vport_delete(struct fc_vport *fc_vport) skip_logo: + /* Remove FC host to break driver binding. */ + fc_remove_host(shost); + scsi_remove_host(shost); + lpfc_cleanup(vport); /* Remove scsi host now. The nodes are cleaned up. */ -- 2.43.0

9 months

1
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024