The mt76x8 subtarget is the only one in ramips that stores the
mediatek,mtd-eeprom property directly in the "root" mt7628an.dtsi.

This is not optimal for a few different reasons:

 * If you don't really know it or are used to other (sub)targets,
   the property will be set somewhat magically.
 * The property is set based on &factory partition before (if at all)
   this partition is defined.
 * There are several devices that have different offset or even
   different partitions to read from, which will then be overwritten
   in the DTS files. Thus, definitions are scattered between root
   DTSI and individual files.

Based on these circumstances, the "root" definition is removed and
the property is added to the device-based DTS(I) files where needed
and applicable. This should be easier to grasp for unexperienced
developers and will move the property closer to the partition
definitions.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

No deleted or manually refreshed patches.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>

While an image layout based on MBR and 'bootfs' partition may be easy
to understand for users who are very used to the IBM PC and always have
the option to access the SD card outside of the device (and hence don't
really depend on other recovery methods or dual-boot), in my opinion
it's a dead end for many desirable features on embedded systems,
especially when managed remotely (and hence without an easy option to
access the SD card using another device in case things go wrong, for
example).

Let me explain:

* using a MSDOS/VFAT filesystem to store kernel(s) is problematic, as a
  single corruption of the bootfs can render the system into a state
  that it no longer boots at all. This makes dual-boot useless, or at
  least very tedious to setup with then 2 independent boot partitions
  to avoid the single point of failure on a "hot" block (the FAT index
  of the boot partition, written every time a file is changed in
  bootfs). And well: most targets even store the bootloader environment
  in a file in that very same FAT filesystem, hence it cannot be used
  to script a reliable dual-boot method (as loading the environment
  itself will already fail if the filesystem is corrupted).

* loading the kernel uImage from bootfs and using rootfs inside an
  additional partition means the bootloader can only validate the
  kernel -- if rootfs is broken or corrupted, this can lead to a reboot
  loop, which is often a quite costly thing to happen in terms of
  hardware lifetime.

* imitating MBR-boot behavior with a FAT-formatted bootfs partition
  (like IBM PC in the 80s and 90s) is just one of many choices on
  embedded targets. There are much better options with modern U-Boot
  (which is what we use and build from source for all targets booting
  off SD cards), see examples in mediatek/mt7622 and mediatek/mt7623.

Hence rename the 'sdcard' feature to 'legacy-sdcard', and prefix
functions with 'legacy_sdcard_' instead of 'sdcard_'.

Tested-by: Stijn Tintel <stijn@linux-ipv6.be>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>

Removed upstreamed bcm27xx/patches-5.4:
    950-0977-USB-gadget-f_hid-avoid-crashes-and-log-spam.patch
    950-0980-SQUASH-USB-gadget-f_hid-remove-more-spam.patch

All other patches automatically rebased.

Build system: x86_64
Build-tested: ipq806x/R7800
Run-tested: ipq806x/R7800

No dmesg regressions, everything functional

Signed-off-by: John Audia <graysky@archlinux.us>

All patches automatically rebased.

Build system: x86_64
Build-tested: ipq806x/R7800
Run-tested: ipq806x/R7800

No dmesg regressions, everything functional

Signed-off-by: John Audia <graysky@archlinux.us>

No deleted or manually refreshed patches.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>

No deleted or manually refreshed patches.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>

This resolves incosnsitencies of the configured RX / TX flow control
modes between different boards or bootloaders.

Signed-off-by: David Bauer <mail@david-bauer.net>

This improves code readability.

Signed-off-by: David Bauer <mail@david-bauer.net>

The chip supports clock speeds up to 50 MHz, however it won't even read
the chip-id correctly at this frequency.

45 MHz however works reliable.

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

Signed-off-by: David Bauer <mail@david-bauer.net>

Fixes commit 91a52f22 ("treewide: backport support for nvmem on non platform devices")

Signed-off-by: David Bauer <mail@david-bauer.net>

When a target configuration has unser Kconfig symbols, the build will
fail when OpenWrt is compiled with V=s and stdin is connected to a tty.

In case OpenWrt is compiled without either of these preconditions, the
build will uscceed with the symbols in question being unset.

Modify the kernel configuration in a way it fails on unset symbols
regardless of the aformentioned preconditions.

Signed-off-by: David Bauer <mail@david-bauer.net>

Calling free for the OF property can result in a kernel panic, as the
buffer in question might be referenced elsewhere. Also, it is not
removed from the tree.

Always allocate a new property and updating the tree with it fixes both
issues.

Fixes commit 91a52f22 ("treewide: backport support for nvmem on non platform devices")

Signed-off-by: David Bauer <mail@david-bauer.net>

The EXT4 driver also takes care of EXT2 and EXT3 file systems.
Activating the EXT2 driver kernel config options unlocked some other
ext2 driver related options which OpenWrt did not take care of.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

The change which backported the of_get_mac_address() change broke some
patches in the layerscape target so the patches did not apply any more.

This commit makes them apply again and also fixes some other problems
related to this change.

Fixes commit 91a52f22 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

The code from ks8851.c was moved to ks8851_common.c, so it was not
backported. This broke the compile of the omap target which uses this
driver.

Fixes commit 91a52f22 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

This patch is backported from linux-arm-kernel [1] to improve situation, when
it was reported that 1.2 GHz variant is unstable with DFS.
It waits to be accepted upstream, however, it waits for Marvell people to respond.

[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/



Fixes: 7b868fe0 ("Revert "mvebu: 5.4 fix DVFS caused random boot crashes"")
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.

This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.

If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.

There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz

This reverts commit 080a0b74.

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html



Fixes: d3794768 ("mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHz")
CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

This option is needed e.g. to use strongswan for IPSec.

BTW: This was the only target where this option was disabled.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>

This uses "hdparm" (if present) to get the harddisk into low
power mode on NAS set-ups.

Cc: Adrian Schmutzler <mail@adrianschmutzler.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

This patch is backported from linux-arm-kernel [1] to improve situation, when
it was reported that 1.2 GHz variant is unstable with DFS.
It waits to be accepted upstream, however, it waits for Marvell people to respond.

[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/



Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.

This leads to the SoC scaling issue not using a CPU parent clock, but
it uses DDR clock. This is done for all variants, and it's wrong because
commits (hacks) that were using the DDR clock are no longer in the mainline kernel.

If someone has stability issues on 1.2 GHz, it should not affect all
routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to
improve the situation in the kernel and not making the situation worse.

There are two solutions in cases of instability:
a) disable cpufreq
b) underclock it up to 1 GHz

This reverts commit 080a0b74.

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html



CC: Pali Rohár <pali@kernel.org>
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>

Follow the recommendations stated in the Turris Omnia DTS for eth2:

"In case SFP module is present, U-Boot has to enable the sfp node above,
remove phy-handle property, and add managed = "in-band-status" property."

The boot script is written in a way, that it works for all U-Boot
versions deployed by the vendor so far (2015.10-rc2, 2019.07).

Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>

Kernel 5.4 receives a reduced set, just to make the SFP cage work.
While we are at it, move the patches accepted upstream to the 0xx series.

Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>

Kernel 5.10 receives the complete set of improvements from 5.11/5.12.
While we are at it, move the patches accepted upstream to the 0xx series.

Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>

PHY_SIMPLE is a bogus kconfig symbol, what we really need to select is
GENERIC_PHY.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>

Add the missing CONFIG_KCSAN (disabled). Found while making kernel_oldconfig on
an x86-64 subtarget.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>

mdio-tools (https://github.com/wkz/mdio-tools) requires the use of
mdio_find_bus, which is not present in 5.4.x.

This patch backports the required change from 5.10.x to 5.4.x

The original patch submission for this can be found at
https://patchwork.ozlabs.org/project/netdev/patch/20200201074625.8698-2-jeremy.linton@arm.com/



Signed-off-by: Damien Mascord <tusker@tusker.org>
[Add original patch description]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

All patches automatically rebased.

Build system: x86_64
Build-tested: ipq806x/R7800
Run-tested: ipq806x/R7800

No dmesg regressions, everything functional

Signed-off-by: John Audia <graysky@archlinux.us>

No deleted or manually refreshed patches.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>

Now that we have a generic sdcard upgrade method, which was copied from
the mvebu platform method, we can switch mvebu to the generic method.

Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

Add a generic sdcard upgrade method instead of duplicating code in yet
another target, and add a feature flag to only install this upgrade
method in targets that set this flag. Copied from mvebu.

Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

kirkwood build broke due to missing include needed for ETH_ALEN.
Add patch (sent upstream as well) to address that.
Refresh patches for 5.4 and 5.10.

Fixes: 91a52f22 ("treewide: backport support for nvmem on non platform devices")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>

As both the Mi Router 4A (100M) and the Mi Router 4C use the same
label-mac-device, the alias can be moved to the shared dtsi.

Signed-off-by: Fabian Bläse <fabian@blaese.de>