Move patch wrongly placed in backport dir to pending dir as they still
didn't got merged upstream.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move MGLRU patches from pending to backport as they got merged upstream.
These are direct porting from one of the dev so it's better to just move
than trying to backport them again from upstream.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move mvebu aardvark patch from pending to backport as they got merged
upstream.
One additional patch is needed as a later fixup for it.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Move sfp HALNy patch from pending to backport as they got merged
upstream. The patch was reordered and one was squashed in the upstream
variant.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
OpenWRT's developer guide prefers having actual patches so they an be
sent upstream more easily.
However, in this case, Adding proper fields also allows for `git am` to
properly function. Some of these patches are quite old, and lack much
traceable history.
This commit tries to rectify that, by digging in the history to find
where and how it was first added.
It is by no means perfect and also shows some patches that should have
been long gone.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Instead of dropping *fix-typo-in-__mtk_foe_entry.patch which effectively
means keeping the (also wrong) assignment of MTK_FOE_STATE_BIND, rather
use MTK_FOE_STATE_INVALID as that works well on both older (NETSYS_V1)
and newer (NETSYS_V2) MediaTek SoCs.
Suggested-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Move and rename patches which were merged upstream and import follow-up
fixes for MediaTek Ethernet offloading features on MT7622 and Filogic
platforms. Remove patch
793-net-ethernet-mtk_eth_soc-fix-typo-in-__mtk_foe_entry.patch
which breaks hardware flow offloading on MT7622, it will be reverted
upstream as well.
Fixes: c93c5365c0 ("kernel: pick patches for MediaTek Ethernet from linux-next")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Fixes situations where MAC address gets incremented multiple times
if device initialization fails at first and then is deferred.
Fixes: d284e6ef0f ("treewide: convert mtd-mac-address-increment* to generic implementation")
Signed-off-by: Will Moss <willormos@gmail.com>
The patch adding support for LEDs connected to a reset controller did
not apply any more, refresh it on top of current master.
Fixes: 53fc987b25 ("generic: move ledbar driver from mediatek target")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Backport a preliminary version of Yu Zhao's multi-generational LRU, for
improved memory management. Refresh the patches while at it.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Add support for in-band managed link status to support SFP cage
connected to port 5 of the MT7531 switch on the Bananapi BPi-R3.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The introduction of the new Airoha target has left the tree in an
unfresh state. Refresh patches to improve that situation.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
It was reported on Turris forum [1] that HALNy HL-GSFP module does not
work as it should with kernel 5.15. Russell King prepared this patch
series, which fixes broken SFP module to work.
Compile and run tested with Turris Omnia.
[1] https://forum.turris.cz/t/hbl-turrisos-6-0-alpha2-halny-hl-gsfp-sfp-gpon-stick-problems/17547
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Import patches from Linux v5.16 and v5.17 to get 2500Base-X SFP working
again with mvneta driver after the generic phylink validate backport.
Fixes: aab466f422 ("kernel: backport generic phylink validate")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Airoha is a new ARM platform based on Cortex-A53 which has recently been
merged into linux-next.
Due to BootROM limitations on this platform, the Cortex-A53 can't run in
Aarch64 mode and code must be compiled for 32-Bit ARM.
This support is based mostly on those linux-next commits backported
for kernel 5.15.
Patches:
1 - platform support = linux-next
2 - clock driver = linux-next
3 - gpio driver = linux-next
4 - linux,usable-memory-range dts support = linux-next
5 - mtd spinand driver
6 - spi driver
7 - pci driver (kconfig only, uses mediatek PCI) = linux-next
Still missing:
- Ethernet driver
- Sysupgrade support
A.t.m there exists one subtarget EN7523 with only one evaluation
board.
The initramfs can be run with the following commands from u-boot:
-
u-boot> setenv bootfile \
openwrt-airoha-airoha_en7523-evb-initramfs-kernel.bin
u-boot> tftpboot
u-boot> bootm 0x81800000
-
Signed-off-by: Daniel Danzberger <daniel@dd-wrt.com>
Backport generic phylink validate series and make use of it for
mtk_eth_soc Ethernet driver as well as mt7530 DSA driver.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Use upstream of_get_mtd_device_by_node() which should behave pretty much
the same. Implementation differences:
get_mtd_device_by_node() of_get_mtd_device_by_node()
---- ----
np->dev.of_node mtd_get_of_node(np)
-EPROBE_DEFER -ENODEV
Cc: Bernhard Frauendienst <openwrt@nospam.obeliks.de>
Cc: Bernhard Frauendienst <kernel@nospam.obeliks.de>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This patches does not have a valid patch headers and does not apply on
an external git tree with 'git am'. To fix this add the missing headers.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Manual rebase by Marty Jones:
bcm27xx/patches-5.15/950-0078-BCM2708-Add-core-Device-Tree-support.patch
All other patches automatically rebased.
Signed-off-by: John Audia <therealgraysky@proton.me>
Signed-off-by: Marty Jones <mj8263788@gmail.com>
[Apply same changes to new dts entry in modified file]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Backport upstream solution that permits to declare nvmem cells with
dynamic partition defined by special parser.
This provide an OF node for NVMEM and connect it to the defined dynamic
partition.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Update this pending patch to remove the untested (variable eraseregions)
section, alongside simplifying the patch.
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
[refresh and split out unrelated refreshes]
Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
Since 4e0c54bc5b ("kernel: add support for kernel 5.4"),
the spi-nor limit 4k erasesize to spi-nor chips below a configured size
patch has not functioned as intended.
For uniform erasesize SPI-NOR devices, both
nor->erase_opcode & mtd->erasesize are used in erase operations.
These are set before, and not modified by, this
CONFIG_MTD_SPI_NOR_USE_4K_SECTORS_LIMIT patch.
Thus, an SPI-NOR device with CONFIG_MTD_SPI_NOR_USE_4K_SECTORS will
always use 4k erasesize (where the device supports it).
If this patch was fixed to function as intended, there would be
cases where devices change from a 4K to a 64K erasesize.
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
1. KCFLAGS should be used for custom flags
2. Optimization flags are arch / SoC specific
3. -fno-reorder-blocks may *worsen* network performace on some SoCs
4. Usage of flags was *reversed* since 5.4 and noone reported that
If we really need custom flags then CONFIG_KERNEL_CFLAGS should get
default value adjusted properly (per target).
Ref: 4e0c54bc5b ("kernel: add support for kernel 5.4")
Link: http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038853.html
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zajec5@gmail.com/
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Rui Salvaterra <rsalvaterra@gmail.com>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
This uses kernel's generic variable and doesn't require patching it with
a custom Makefile change. It's expected *not* to change any behaviour.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Linux' upstream MTD-Maintainer Miquèl Raynal noted:
|Reverting seems the safest option here, not knowing how many devices
|have these damaged/counterfeit chips. If it is just a couple and only on
|Fritzboxes, as suggested in the Github issue this patch could be
|carried through OpenWrt and that would seem more future proof IMHO.
This patch follows up with the first patch. It actually
moves the patches out of target/linux/generic/pending into
the ipq40xx's patch heap and adds a little note what happend.
For more information, discussions or reports about bad TC58NVG0S3Hs,
please visit the OpenWrt's Github Issue #9962:
<https://github.com/openwrt/openwrt/issues/9962>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Delete the crypto-lib-blake2s kmod package, as BLAKE2s is now built-in.
Patches automatically rebased.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Hannu Nyman wrote in openwrt's github issue #9962:
|Based on forum discussion, the commit 0bc794a
|"kernel: add support for Toshiba TC58NVG0S3HTA00 NAND flash"
|causes flash memory chip misdetection for some other
|Fritzbox devices, as the commit only defines a 4-byte flash
|memory chip ID that matches several chips used in the devices.
|
|See discussion from this onward
|<https://forum.openwrt.org/t/openwrt-22-03-0-rc1-first-release-candidate/126045/182>
|
|OpenWrt 22.03.0-rc2 and rc3 are causing on a Fritzbox 7412
|bootloops due to a misdetected flash chip.
|
|Yup, that patch is missing the 5th ID byte entirely - both chips
|share the same first 4;
|
| TC58NVG0S3HTA00 = 0x98 0xf1 0x80 0x15 0x72 (digikey datasheet, page 35)
| TC58BVG0S3HTA00 = 0x98 0xf1 0x80 0x15 0xf2 (digikey datasheet, page 28)
|
|The commit has also been backported to openwrt-22.03 after rc1,
|so both rc2 and rc3 suffer from this bug."
Andreas' TC58NVG0S3H seems not to follow Toshibas/Kioxa's own datasheet.
It only reports the first four bytes: "98 f1 80 15 00 00 00 00".
This patch changes the id_len in the entry to 8. This makes it so that
Andreas' NAND is still detected. At the same time, this prevents other
Toshiba NAND flash chips - that share the same four bytes - from being
misdetected.
The issue has been reported upstream, since they also accepted the initial
patch... so if not addressed, 5.19/5.20 will also break those affected
devices again.
Reported-by: Peter-vdL
Fixes: 0bc794a668 ("kernel: add support for Toshiba TC58NVG0S3HTA00 NAND flash")
Link: <https://github.com/openwrt/openwrt/issues/9962>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The current reworked version cause kernel panic when the value is changes and
an interface is up. Following the tcp_be_liberal impelementation,
reimplement this to permit a safe change of this value without any
panic.
This has been tested with a QSDK package where tcp_no_window_check is used.
Fixes: 92fb51bc98 ("generic: 5.15: standardize tcp_no_window_check pending patch")
Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
The Toshiba TC58NVG0S3HTA00 is detected with 64 byte OOB while the flash
has 128 byte OOB. This adds a static NAND ID entry to correct this.
Signed-off-by: Andreas Böhler <dev@aboehler.at>
Standardize pending patch tcp_no_window_check patch as with
new kernel they added a check for global variables.
The 2 new condition are that they must be read-only or
the data pointer should not point to kernel/module global
data.
Remove the global variable and move it to a standard place
following other variables logic.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
