mirror of
https://github.com/coolsnowwolf/lede.git
synced 2025-06-15 16:15:29 +08:00

* kernel: bump 5.15 to 5.15.86 Removed upstreamed: pending-5.15/101-Use-stddefs.h-instead-of-compiler.h.patch[1] ipq60xx/patches-5.15/0171-arm64-dts-qcom-ipq6018-cp01-c1-use-BLSPI1-pins.patch ipq806x/patches-5.15/122-01-clk-qcom-clk-krait-fix-wrong-div2-functions.patch[2] ipq60xx/patches-5.15/0139-arm64-dts-qcom-Correct-QMP-PHY-child-node-name.patch ipq60xx/patches-5.15/0005-v5.16-arm64-dts-qcom-Correct-QMP-PHY-child-node-name.patch ipq807x/patches-5.15/0004-v5.16-arm64-dts-qcom-Correct-QMP-PHY-child-node-name.patch bcm27xx/patches-5.15/950-0198-drm-fourcc-Add-packed-10bit-YUV-4-2-0-format.patch[3] Manually rebased: ramips/patches-5.15/100-PCI-mt7621-Add-MediaTek-MT7621-PCIe-host-controller-.patch[4] Added patch/backported: ramips/patches-5.15/107-PCI-mt7621-Add-sentinel-to-quirks-table.patch[5] All other patches automatically rebased. 1. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.86&id=c160505c9b574b346031fdf2c649d19e7939ca11 2. Cannot find in the stable tree but it is here:a051e10bfc
3.ec1727f89e
4. Quilt gave this output when I applied the patch to rebase it: % quilt push -f Applying patch platform/100-PCI-mt7621-Add-MediaTek-MT7621-PCIe-host-controller-.patch patching file arch/mips/ralink/Kconfig patching file drivers/pci/controller/Kconfig patching file drivers/pci/controller/Makefile patching file drivers/staging/Kconfig patching file drivers/staging/Makefile patching file drivers/staging/mt7621-pci/Kconfig patching file drivers/staging/mt7621-pci/Makefile patching file drivers/staging/mt7621-pci/TODO patching file drivers/staging/mt7621-pci/mediatek,mt7621-pci.txt patching file drivers/staging/mt7621-pci/pci-mt7621.c Hunk #1 FAILED at 1. Not deleting file drivers/staging/mt7621-pci/pci-mt7621.c as content differs from patch 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/mt7621-pci/pci-mt7621.c.rej patching file drivers/pci/controller/pcie-mt7621.c Applied patch platform/100-PCI-mt7621-Add-MediaTek-MT7621-PCIe-host-controller-.patch (forced; needs refresh) Upon inspecting drivers/staging/mt7621-pci/pci-mt7621.c.rej, it seems that the original patch wants to delete drivers/staging/mt7621-pci/pci-mt7621.c but upstream's version was not an exact match. I opted to delete that file and need some feedback. Was that the correct course of action? 5. Suggestion by hauke:19098934f9
"This patch is in upstream kernel, but it was backported to the old staging driver in kernel 5.15." Build system: x86_64 Build-tested: bcm2711/RPi4B, filogic/xiaomi_redmi-router-ax6000-ubootmod Run-tested: bcm2711/RPi4B, filogic/xiaomi_redmi-router-ax6000-ubootmod Signed-off-by: John Audia <therealgraysky@proton.me> Signed-off-by: Linhui Liu <liulinhui36@gmail.com> * oxnas: sata_oxnas: use ata_link_err Kernel 5.15.86 has backported ("ata: libata: move ata_{port,link,dev}_dbg to standard pr_XXX() macros") and this is now causing compilation errors for oxnas SATA driver due to usage of ata_link_printk(). Upstream has migrated to using the appropriate ata_link_{err, warn, notice, info} calls a while ago so its not affected. Lets do the same for oxnas SATA driver and use ata_link_err() instead of ata_link_printk(). Signed-off-by: Robert Marko <robimarko@gmail.com> Signed-off-by: John Audia <therealgraysky@proton.me> Signed-off-by: Linhui Liu <liulinhui36@gmail.com> Signed-off-by: Robert Marko <robimarko@gmail.com> Co-authored-by: John Audia <therealgraysky@proton.me> Co-authored-by: Robert Marko <robimarko@gmail.com>
43 lines
1.7 KiB
Diff
43 lines
1.7 KiB
Diff
From db675d9894cea3a30ba50695a3e1ea9739782bd2 Mon Sep 17 00:00:00 2001
|
|
From: Phil Elwell <phil@raspberrypi.org>
|
|
Date: Wed, 29 Jan 2020 09:35:19 +0000
|
|
Subject: [PATCH] tty: amba-pl011: Avoid rare write-when-full error
|
|
|
|
Under some circumstances on BCM283x processors data loss can be
|
|
observed - a single byte missing from the TX output stream. These bytes
|
|
are always the last byte of a batch of 8 written from pl011_tx_chars
|
|
when from_irq is true, meaning that the FIFO full flag is not checked
|
|
before writing.
|
|
|
|
The transmit optimisation relies on the FIFO being half-empty when the
|
|
TX interrupt is raised. Instrumenting the driver further showed that
|
|
the failure case correlated with the TX FIFO full flag being set at the
|
|
point where the last byte was written to the data register, which
|
|
explains the data loss but not how the FIFO appeared to be prematurely
|
|
full. A possible explanation is that a FIFO write was in flight at the
|
|
time the interrupt was raised, but as yet there is no hypothesis as to
|
|
how this might occur.
|
|
|
|
In the absence of a clear understanding of the failure mechanism, avoid
|
|
the problem by checking the FIFO levels before writing the last byte of
|
|
the group, which will have minimal performance impact.
|
|
|
|
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
|
|
---
|
|
drivers/tty/serial/amba-pl011.c | 4 ++++
|
|
1 file changed, 4 insertions(+)
|
|
|
|
--- a/drivers/tty/serial/amba-pl011.c
|
|
+++ b/drivers/tty/serial/amba-pl011.c
|
|
@@ -1496,6 +1496,10 @@ static bool pl011_tx_chars(struct uart_a
|
|
if (likely(from_irq) && count-- == 0)
|
|
break;
|
|
|
|
+ if (likely(from_irq) && count == 0 &&
|
|
+ pl011_read(uap, REG_FR) & UART01x_FR_TXFF)
|
|
+ break;
|
|
+
|
|
if (!pl011_tx_char(uap, xmit->buf[xmit->tail], from_irq))
|
|
break;
|
|
|