April 2022 - Linux-stable-mirror

[PATCH 1/2] PCI: qcom: fix runtime PM imbalance on probe errors

by Johan Hovold

Drop the leftover pm_runtime_disable() calls from the late probe error paths that would, for example, prevent runtime PM from being reenabled after a probe deferral. Fixes: 6e5da6f7d824 ("PCI: qcom: Fix error handling in runtime PM support") Cc: stable(a)vger.kernel.org # 4.20 Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/pci/controller/dwc/pcie-qcom.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index 20a0e6533a1c..0b0bd71f1bd2 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1616,17 +1616,14 @@ static int qcom_pcie_probe(struct platform_device *pdev) pp->ops = &qcom_pcie_dw_ops; ret = phy_init(pcie->phy); - if (ret) { - pm_runtime_disable(&pdev->dev); + if (ret) goto err_pm_runtime_put; - } platform_set_drvdata(pdev, pcie); ret = dw_pcie_host_init(pp); if (ret) { dev_err(dev, "cannot initialize host\n"); - pm_runtime_disable(&pdev->dev); goto err_pm_runtime_put; } -- 2.35.1

2 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] can: m_can: m_can_tx_handler(): fix use after free of skb" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2e8e79c416aae1de224c0f1860f2e3350fa171f8 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde <mkl(a)pengutronix.de> Date: Thu, 17 Mar 2022 08:57:35 +0100 Subject: [PATCH] can: m_can: m_can_tx_handler(): fix use after free of skb can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch. Fixes: 80646733f11c ("can: m_can: update to support CAN FD features") Link: https://lore.kernel.org/all/20220317081305.739554-1-mkl@pengutronix.de Cc: stable(a)vger.kernel.org Reported-by: Hangyu Hua <hbh25y(a)gmail.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c index 1a4b56f6fa8c..b3b5bc1c803b 100644 --- a/drivers/net/can/m_can/m_can.c +++ b/drivers/net/can/m_can/m_can.c @@ -1637,8 +1637,6 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev) if (err) goto out_fail; - can_put_echo_skb(skb, dev, 0, 0); - if (cdev->can.ctrlmode & CAN_CTRLMODE_FD) { cccr = m_can_read(cdev, M_CAN_CCCR); cccr &= ~CCCR_CMR_MASK; @@ -1655,6 +1653,9 @@ static netdev_tx_t m_can_tx_handler(struct m_can_classdev *cdev) m_can_write(cdev, M_CAN_CCCR, cccr); } m_can_write(cdev, M_CAN_TXBTIE, 0x1); + + can_put_echo_skb(skb, dev, 0, 0); + m_can_write(cdev, M_CAN_TXBAR, 0x1); /* End of xmit function for version 3.0.x */ } else {

2 years, 1 month

1
0
0 0

Re: Patch "serial: sc16is7xx: Clear RS485 bits in the shutdown" has been added to the 4.9-stable tree

by Hui Wang

Hi Greg, Sorry, please don't apply the patch to stable kernels. I tried to add "linux,rs485-enabled-at-boot-time" support for this driver yesterday and found this patch is not correct, I will send a patch to revert this patch from the mainline kernel. Thanks, Hui. On 4/1/22 18:38, gregkh(a)linuxfoundation.org wrote: > This is a note to let you know that I've just added the patch titled > > serial: sc16is7xx: Clear RS485 bits in the shutdown > > to the 4.9-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch > and it can be found in the queue-4.9 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. > > > >From 927728a34f11b5a27f4610bdb7068317d6fdc72a Mon Sep 17 00:00:00 2001 > From: Hui Wang <hui.wang(a)canonical.com> > Date: Tue, 8 Mar 2022 19:00:42 +0800 > Subject: serial: sc16is7xx: Clear RS485 bits in the shutdown > > From: Hui Wang <hui.wang(a)canonical.com> > > commit 927728a34f11b5a27f4610bdb7068317d6fdc72a upstream. > > We tested RS485 function on an EVB which has SC16IS752, after > finishing the test, we started the RS232 function test, but found the > RTS is still working in the RS485 mode. > > That is because both startup and shutdown call port_update() to set > the EFCR_REG, this will not clear the RS485 bits once the bits are set > in the reconf_rs485(). To fix it, clear the RS485 bits in shutdown. > > Cc: <stable(a)vger.kernel.org> > Signed-off-by: Hui Wang <hui.wang(a)canonical.com> > Link: https://lore.kernel.org/r/20220308110042.108451-1-hui.wang@canonical.com > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > drivers/tty/serial/sc16is7xx.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > --- a/drivers/tty/serial/sc16is7xx.c > +++ b/drivers/tty/serial/sc16is7xx.c > @@ -1055,10 +1055,12 @@ static void sc16is7xx_shutdown(struct ua > > /* Disable all interrupts */ > sc16is7xx_port_write(port, SC16IS7XX_IER_REG, 0); > - /* Disable TX/RX */ > + /* Disable TX/RX, clear auto RS485 and RTS invert */ > sc16is7xx_port_update(port, SC16IS7XX_EFCR_REG, > SC16IS7XX_EFCR_RXDISABLE_BIT | > - SC16IS7XX_EFCR_TXDISABLE_BIT, > + SC16IS7XX_EFCR_TXDISABLE_BIT | > + SC16IS7XX_EFCR_AUTO_RS485_BIT | > + SC16IS7XX_EFCR_RTS_INVERT_BIT, > SC16IS7XX_EFCR_RXDISABLE_BIT | > SC16IS7XX_EFCR_TXDISABLE_BIT); > > > > Patches currently in stable-queue which might be from hui.wang(a)canonical.com are > > queue-4.9/serial-sc16is7xx-clear-rs485-bits-in-the-shutdown.patch

2 years, 1 month

2
1
0 0

[PATCH RESEND] PCI: qcom: fix pipe clock imbalance

by Johan Hovold

Commit ed8cc3b1fc84 ("PCI: qcom: Add support for SDM845 PCIe controller") introduced a clock imbalance by enabling the pipe clock both in init() and in post_init() but only disabling in post_deinit(). Note that the pipe clock was also never disabled in the init() error paths and that enabling the clock before powering up the PHY looks questionable. Fixes: ed8cc3b1fc84 ("PCI: qcom: Add support for SDM845 PCIe controller") Cc: stable(a)vger.kernel.org # 5.6 Cc: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- Resending with lists on CC. Johan drivers/pci/controller/dwc/pcie-qcom.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c index b79d98e5e228..20a0e6533a1c 100644 --- a/drivers/pci/controller/dwc/pcie-qcom.c +++ b/drivers/pci/controller/dwc/pcie-qcom.c @@ -1238,12 +1238,6 @@ static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie) goto err_disable_clocks; } - ret = clk_prepare_enable(res->pipe_clk); - if (ret) { - dev_err(dev, "cannot prepare/enable pipe clock\n"); - goto err_disable_clocks; - } - /* Wait for reset to complete, required on SM8450 */ usleep_range(1000, 1500); -- 2.35.1

2 years, 1 month

1
0
0 0

Re: kernel 5.16.12 and above broke yoga c930 sound and mic

by Greg KH

On Wed, Mar 30, 2022 at 04:54:53PM -0400, Joshua Freedman wrote: > This felt really anti-climactic haha, but hopefully it's useful? > cat bisect.log > Bisecting: 81 revisions left to test after this (roughly 6 steps) > [770aac3c84e0c83a19985413fa9fbfc126cc0ff6] net: mdio-ipq4019: add delay > after clock enable Wait, you still have more steps to go here. Did you test this kernel? If so, you need to continue using 'git bisect good' and 'git bisect bad' to find the offending commit. This looks just like the first step? thanks, greg k-h

2 years, 1 month

1
0
0 0

Re: kernel 5.16.12 and above broke yoga c930 sound and mic

by Greg KH

On Wed, Mar 30, 2022 at 04:54:53PM -0400, Joshua Freedman wrote: > This felt really anti-climactic haha, but hopefully it's useful? > cat bisect.log > Bisecting: 81 revisions left to test after this (roughly 6 steps) > [770aac3c84e0c83a19985413fa9fbfc126cc0ff6] net: mdio-ipq4019: add delay > after clock enable Ok, great! Can you start a new thread and add the developers of that change to to it to help track down the issue? thanks, greg k-h

2 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] mtd: rawnand: protect access to rawnand devices while in" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8cba323437a49a45756d661f500b324fc2d486fe Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Tue, 8 Feb 2022 09:52:13 +0100 Subject: [PATCH] mtd: rawnand: protect access to rawnand devices while in suspend Prevent rawnand access while in a suspended state. Commit 013e6292aaf5 ("mtd: rawnand: Simplify the locking") allows the rawnand layer to return errors rather than waiting in a blocking wait. Tested on a iMX6ULL. Fixes: 013e6292aaf5 ("mtd: rawnand: Simplify the locking") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220208085213.1838273-1-sean@geanix.com diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 3e4a525ac3ca..612ae60e9763 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -338,16 +338,19 @@ static int nand_isbad_bbm(struct nand_chip *chip, loff_t ofs) * * Return: -EBUSY if the chip has been suspended, 0 otherwise */ -static int nand_get_device(struct nand_chip *chip) +static void nand_get_device(struct nand_chip *chip) { - mutex_lock(&chip->lock); - if (chip->suspended) { + /* Wait until the device is resumed. */ + while (1) { + mutex_lock(&chip->lock); + if (!chip->suspended) { + mutex_lock(&chip->controller->lock); + return; + } mutex_unlock(&chip->lock); - return -EBUSY; - } - mutex_lock(&chip->controller->lock); - return 0; + wait_event(chip->resume_wq, !chip->suspended); + } } /** @@ -576,9 +579,7 @@ static int nand_block_markbad_lowlevel(struct nand_chip *chip, loff_t ofs) nand_erase_nand(chip, &einfo, 0); /* Write bad block marker to OOB */ - ret = nand_get_device(chip); - if (ret) - return ret; + nand_get_device(chip); ret = nand_markbad_bbm(chip, ofs); nand_release_device(chip); @@ -3826,9 +3827,7 @@ static int nand_read_oob(struct mtd_info *mtd, loff_t from, ops->mode != MTD_OPS_RAW) return -ENOTSUPP; - ret = nand_get_device(chip); - if (ret) - return ret; + nand_get_device(chip); if (!ops->datbuf) ret = nand_do_read_oob(chip, from, ops); @@ -4415,13 +4414,11 @@ static int nand_write_oob(struct mtd_info *mtd, loff_t to, struct mtd_oob_ops *ops) { struct nand_chip *chip = mtd_to_nand(mtd); - int ret; + int ret = 0; ops->retlen = 0; - ret = nand_get_device(chip); - if (ret) - return ret; + nand_get_device(chip); switch (ops->mode) { case MTD_OPS_PLACE_OOB: @@ -4481,9 +4478,7 @@ int nand_erase_nand(struct nand_chip *chip, struct erase_info *instr, return -EIO; /* Grab the lock and see if the device is available */ - ret = nand_get_device(chip); - if (ret) - return ret; + nand_get_device(chip); /* Shift to get first page */ page = (int)(instr->addr >> chip->page_shift); @@ -4570,7 +4565,7 @@ static void nand_sync(struct mtd_info *mtd) pr_debug("%s: called\n", __func__); /* Grab the lock and see if the device is available */ - WARN_ON(nand_get_device(chip)); + nand_get_device(chip); /* Release it and go back */ nand_release_device(chip); } @@ -4587,9 +4582,7 @@ static int nand_block_isbad(struct mtd_info *mtd, loff_t offs) int ret; /* Select the NAND device */ - ret = nand_get_device(chip); - if (ret) - return ret; + nand_get_device(chip); nand_select_target(chip, chipnr); @@ -4660,6 +4653,8 @@ static void nand_resume(struct mtd_info *mtd) __func__); } mutex_unlock(&chip->lock); + + wake_up_all(&chip->resume_wq); } /** @@ -5438,6 +5433,7 @@ static int nand_scan_ident(struct nand_chip *chip, unsigned int maxchips, chip->cur_cs = -1; mutex_init(&chip->lock); + init_waitqueue_head(&chip->resume_wq); /* Enforce the right timings for reset/detection */ chip->current_interface_config = nand_get_reset_interface_config(); diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h index 5b88cd51fadb..dcf90144d70b 100644 --- a/include/linux/mtd/rawnand.h +++ b/include/linux/mtd/rawnand.h @@ -1240,6 +1240,7 @@ struct nand_secure_region { * @lock: Lock protecting the suspended field. Also used to serialize accesses * to the NAND device * @suspended: Set to 1 when the device is suspended, 0 when it's not + * @resume_wq: wait queue to sleep if rawnand is in suspended state. * @cur_cs: Currently selected target. -1 means no target selected, otherwise we * should always have cur_cs >= 0 && cur_cs < nanddev_ntargets(). * NAND Controller drivers should not modify this value, but they're @@ -1294,6 +1295,7 @@ struct nand_chip { /* Internals */ struct mutex lock; unsigned int suspended : 1; + wait_queue_head_t resume_wq; int cur_cs; int read_retries; struct nand_secure_region *secure_regions;

2 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 151c6b49d679872d6fc0b50e0ad96303091694a2 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)microchip.com> Date: Mon, 28 Feb 2022 18:33:34 +0200 Subject: [PATCH] mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set Even if SPI_NOR_NO_ERASE was set, one could still send erase opcodes to the flash. It is not recommended to send unsupported opcodes to flashes. Fix the logic and do not set mtd->_erase when SPI_NOR_NO_ERASE is specified. With this users will not be able to issue erase opcodes to flashes and instead they will recive an -ENOTSUPP error. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Reviewed-by: Michael Walle <michael(a)walle.cc> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20220228163334.277730-1-tudor.ambarus@microchip.c… diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 9014008e60b3..b4f141ad9c9c 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2948,10 +2948,11 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) mtd->flags = MTD_CAP_NORFLASH; if (nor->info->flags & SPI_NOR_NO_ERASE) mtd->flags |= MTD_NO_ERASE; + else + mtd->_erase = spi_nor_erase; mtd->writesize = nor->params->writesize; mtd->writebufsize = nor->params->page_size; mtd->size = nor->params->size; - mtd->_erase = spi_nor_erase; mtd->_read = spi_nor_read; /* Might be already set by some SST flashes. */ if (!mtd->_write)

2 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set" failed to apply to 5.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.16-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 151c6b49d679872d6fc0b50e0ad96303091694a2 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)microchip.com> Date: Mon, 28 Feb 2022 18:33:34 +0200 Subject: [PATCH] mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set Even if SPI_NOR_NO_ERASE was set, one could still send erase opcodes to the flash. It is not recommended to send unsupported opcodes to flashes. Fix the logic and do not set mtd->_erase when SPI_NOR_NO_ERASE is specified. With this users will not be able to issue erase opcodes to flashes and instead they will recive an -ENOTSUPP error. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Reviewed-by: Michael Walle <michael(a)walle.cc> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20220228163334.277730-1-tudor.ambarus@microchip.c… diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 9014008e60b3..b4f141ad9c9c 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2948,10 +2948,11 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) mtd->flags = MTD_CAP_NORFLASH; if (nor->info->flags & SPI_NOR_NO_ERASE) mtd->flags |= MTD_NO_ERASE; + else + mtd->_erase = spi_nor_erase; mtd->writesize = nor->params->writesize; mtd->writebufsize = nor->params->page_size; mtd->size = nor->params->size; - mtd->_erase = spi_nor_erase; mtd->_read = spi_nor_read; /* Might be already set by some SST flashes. */ if (!mtd->_write)

2 years, 1 month

1
0
0 0

FAILED: patch "[PATCH] mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 151c6b49d679872d6fc0b50e0ad96303091694a2 Mon Sep 17 00:00:00 2001 From: Tudor Ambarus <tudor.ambarus(a)microchip.com> Date: Mon, 28 Feb 2022 18:33:34 +0200 Subject: [PATCH] mtd: spi-nor: Skip erase logic when SPI_NOR_NO_ERASE is set Even if SPI_NOR_NO_ERASE was set, one could still send erase opcodes to the flash. It is not recommended to send unsupported opcodes to flashes. Fix the logic and do not set mtd->_erase when SPI_NOR_NO_ERASE is specified. With this users will not be able to issue erase opcodes to flashes and instead they will recive an -ENOTSUPP error. Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR") Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Reviewed-by: Michael Walle <michael(a)walle.cc> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20220228163334.277730-1-tudor.ambarus@microchip.c… diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c index 9014008e60b3..b4f141ad9c9c 100644 --- a/drivers/mtd/spi-nor/core.c +++ b/drivers/mtd/spi-nor/core.c @@ -2948,10 +2948,11 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor) mtd->flags = MTD_CAP_NORFLASH; if (nor->info->flags & SPI_NOR_NO_ERASE) mtd->flags |= MTD_NO_ERASE; + else + mtd->_erase = spi_nor_erase; mtd->writesize = nor->params->writesize; mtd->writebufsize = nor->params->page_size; mtd->size = nor->params->size; - mtd->_erase = spi_nor_erase; mtd->_read = spi_nor_read; /* Might be already set by some SST flashes. */ if (!mtd->_write)

2 years, 1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2022