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>
