Import some accepted and pending upstream patches for mtk_eth_soc,
replacing some semantically equivalent local patches and fixing issues
when operating the PCS in 1G SGMII mode.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The patch that adds support for hw flow-offloading counters on newer
MediaTek SoCs tries to prints acct->packets and acct->bytes in debugfs,
without checking that acct isn't null. This causes a kernel panic when
trying to read /sys/kernel/debug/ppe0/entries on older MediaTek SoCs.
Fix this by adding a check for acct.
Fixes: 9721a42a27 ("kernel: support hw flow-offloading counters on newer MediaTek SoCs")
Reported-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fix Silicon Labs bindings in the spidev driver
Some bindings for Silicon Labs chips already exists upstream.
These bindings can be found in trivial-devices.yaml.
The existing bindings are using "silabs" instead of "siliconlabs" to
identify the manufacturer.
This commit add two submitted patches for silabs chips and rename the
manufacturer in the different DTS for more coherence.
Signed-off-by: Vincent Tremblay <vincent@vtremblay.dev>
Backport patch from kernel 5.14.
Treat only the highest, not the lowest, IPv4 address within a local
subnet as a broadcast address, as subnets do not need two different
broadcast addresses and networking documentation consistently prefers
the highest address as broadcast.
This patch was merged in upstream net-next tree in May 2021 at
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=94c821c74bf5
This eventually frees up one address per subnet. It matches behavior
suggested in our Internet-Draft, and also the default behavior of OpenBSD
and FreeBSD.
Signed-off-by: Seth David Schoen <schoen@loyalty.org>
* 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>
In the build of the ramips/mt76x8 target the user gets asked about these
two configuration options, add them to the generic kernel configuration.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The CONFIG_DRM_XEN_FRONTEND configuration symbol is also used by the
layerscape target, move it to the generic kernel configuration.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
nvmem_cell_read return a pointer error when an error occurs. Currently
we convert the pointer error to an int while the rest of the function
return a void* and expcet an error pointer. Fix this PTR_ERR msuse
fixing compilation warning.
Fixes the following compilation warning:
net/ethernet/eth.c: In function 'nvmem_cell_get_mac_address':
net/ethernet/eth.c:547:24: warning: returning 'long int' from a function with return type 'void *' makes pointer from integer without a cast [-Wint-conversion]
547 | return PTR_ERR(mac);
| ^~~~~~~~~~~~
net/ethernet/eth.c: In function 'nvmem_cell_get_mac_address_ascii':
net/ethernet/eth.c:564:24: warning: returning 'long int' from a function with return type 'void *' makes pointer from integer without a cast [-Wint-conversion]
564 | return PTR_ERR(mac_ascii);
| ^~~~~~~~~~~~~~~~~~
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
* kernel: bump 5.10 to 5.10.160
No patches affected by this update.
Build system: x86_64
Build-tested: ramips/tplink_archer-a6-v3
Run-tested: ramips/tplink_archer-a6-v3
Signed-off-by: John Audia <therealgraysky@proton.me>
* kernel: bump 5.15 to 5.15.84
Signed-off-by: John Audia <therealgraysky@proton.me>
* kernel: bump 5.4 to 5.4.228
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
Signed-off-by: John Audia <therealgraysky@proton.me>
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
Co-authored-by: John Audia <therealgraysky@proton.me>
enable option `CONFIG_CRYPTO_LZ4HC` to match default kernel config
this only adds the `lz4hc_compress` module, and has no effect on the
`lz4_decompress` module which already supports any flavor
Signed-off-by: Tony Butler <spudz76@gmail.com>
Kernel 5.10.158 added a prompt for the FUNCTION_ERROR_INJECTION symbol.
This is exposed in builds with CONFIG_KERNEL_KPROBES enabled, causing
those builds to fail due to a missing symbol. Add the symbol to fix
this.
Fixes: 6801c460b6a7 ("kernel: bump 5.10 to 5.10.158")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Kernel 5.15.82 added a prompt for the FUNCTION_ERROR_INJECTION symbol.
This is exposed in builds with CONFIG_KERNEL_KPROBES enabled, causing
those builds to fail due to a missing symbol. Add the symbol to fix
this.
Fixes: 68426e54eda4 ("kernel: bump 5.15 to 5.15.82")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* kernel: bump 5.15 to 5.15.83
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
* kernel: bump 5.10 to 5.10.159
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
* kernel: bump 5.4 to 5.4.227
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>
Signed-off-by: Linhui Liu <liulinhui36@gmail.com>