L2 learning on the CPU port is currently not consistently configured and
relies on the default configuration of the device. On RTL83xx, it is
disabled for packets transmitted with a TX header, as hardware learning
corrupts the forwarding table otherwise. As a result, unneeded flooding
of traffic for the CPU port can already happen on some devices now. It
is also likely that similar issues exist on RTL93xx, which doesn't have
a field to disable learning in the TX header.
To address this, disable hardware learning for the CPU port globally on
all devices. Instead, enable assisted learning to let DSA write FDB
entries to the switch.
For now, this does not sync local/bridge entries to the switch. However,
support for that was added in Linux 5.14, so the next switch to a newer
kernel version is going to fix this.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Initialize the data structure using memset to avoid the possibility of
writing garbage values to the hardware.
Always set a valid entry type, which should fix writing unicast entries
on RTL930x.
For unicast entries, set the is_static flag to prevent the switch from
aging them out.
Also set the rvid field for unicast entries. This is not strictly
necessary, as the switch fills it in automatically from a non-zero vid.
However, this makes the code consistent with multicast entry setup.
While at it, reorder the statements and fix some style issues (double
space, comma instead of semicolon at end of statement). Also remove the
unneeded priv parameter and debug print for the multicast entry setup
function.
Fixes: cde31976e3 ("realtek: Add support for Layer 2 Multicast")
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Commit e8b5429609 included an unintended change and we now call
scan_wifi before a network reload.
Restore the original behaviour and call scan_wifi only after a network
reload.
Fixes: e8b5429609 ("base-files: wifi: tidy up the reconf code")
Signed-off-by: Bob Cantor <bobc@confidesk.com>
Commit b82cc80713 included an unintended change and we now call
scan_wifi before a network reload.
Restore the original behaviour and call scan_wifi only after a network
reload.
Fixes: b82cc80713 ("base-files: wifi: swap the order of some ubus calls")
Signed-off-by: Bob Cantor <bobc@confidesk.com>
This patch was wrongly dropped with the assumption that it was moved to
generic. This wasn't the case and caused the malfunction of the Asrock
G10 router.
Reintroduce it to fix Asrock G10 functionality.
Fixes: 8cc2caed58 ("ipq806x: 5:15: add testing kernel version")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Zyxel NGB6817 is the only router that use mmc for rootfs. Upstream
kernel dtsi have mmc-ddr-1_8v enabled for sddc1. This is wrong as mmc on
ipq806x is supplied by a fixed 3.3v regulator and can't operate at 1.8v.
This cause the sddc1 to malfunction and cause kernel panic.
In old 5.15 version this was disabled but it was put in addition to many
other changes so it was dropped silently. Restore this patch to fix
working condition of such router.
Fixes: 88bf652 ("ipq806x: 5.15: replace dtsi patches with upstream version")
Fixes: #11000
Tested-by: Hendrik Koerner <koerhen@web.de>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
In refreshing DTS to the upstream version an unwanted change slipped in
the commit. The ASRock G10 dts got converted to DSA without any support.
Revert this to swconfig driver to restore normal functionality.
Fixes: 88bf652525 ("ipq806x: 5.15: replace dtsi patches with upstream version")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
We currently ignore ret of the nandc partition parser if unprotected
spare data is true. This is the case for ipq806x nand.
Backport patch that fix this error and correctly handle error from
partition parser.
Fixes: ae6a63bc97 ("ipq806x: 5.15: replace nandc patch with upstream version")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Backport patch from kernel 5.15 that mute error on EPROBE_DEFER with
smempart parser.
This parser require the smem device to be probed first and currently it
may happen that mtd gets probed before the smem device causing an error
on the smempart parser. This error may be confusing and should be muted.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
In new kernel version from 5.16, smem node can be declared directly in
the reserved-space node. Upstream ipq806x (and to-be-merged) ipq807x
allign to this new implementation. Backport this patch to kernel 5.15 to
fix support for smem parser for ipq806x target.
Fixes: 88bf652525 ("ipq806x: 5.15: replace dtsi patches with upstream version")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
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>
CONFIG_MAC80211_MESH isn't defined for this package, rendering the patch
useless. Match protecting the access of sta_info.mesh with the very same
define declaring it.
Fixes 45109f69a6 "mac80211: fix compile error when mesh is disabled"
Signed-off-by: Andre Heider <a.heider@gmail.com>
This updates mac80211 to version 5.15.74-1 which is based on kernel
5.15.74.
The removed patches were applied upstream.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The switches support different actions for incoming ethernet multicast
frames with Reserved Multicast Addresses (01-80-C2-00-00-{01-2F}). The
current code will set the 2-bit action field to FLOOD (0x3) for most
classes, but the highest bit is always unset for the relevant control
registers. This means the DROP (0x1) action being used for these
classes; whatever class the MSB happens to be in.
For RTL838x, this results in {20,23-2F} frames being dropped, instead of
flooding all ports. On other switch generations, {0F,1F,2F} frames are
dropped. This is inconsistent, and appears to be a mistake. Remove this
inconsistency by flooding all multicast frames with RMA addresses.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The multicast setup function rtl838x_eth_set_multicast_list() checks if
the current SoC is a RTL839x family device. However, the function is
only included in the RTL838x ops table, so this path should never be
taken, making this dead code. rtl839x_eth_set_multicast_list() is
already present in the RTL839x ops table, so it should be safe to remove
this branch.
While touching the code, also re-sort the functions to match sorting
elsewhere, with rtl838x coming before rtl839x.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Currently several messages at KERN_INFO level are printed for every FDB
del/dump operation. This can cause a significant slowdown for example
while using "bridge fdb", and may even trigger a watchdog.
Remove most of these log messages, as the new L2 table debugfs node
should be a good replacement. Change the remaining messages to
KERN_DEBUG level.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Switch to a polling implementation similar to the one for RTL838x, to
allow other kernel tasks to run while waiting.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
The new timer is not yet ready for all targets. Avoid interactive
questions during build
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[rename symbol to CONFIG_REALTEK_OTTO_TIMER]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Use the new timer driver for the RTL839X devices and remove the
no longer needed modules.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct timer compatible order, update selected symbols]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Use the new timer driver for the RTL838X devices. Remove the no
longer needed modules.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct timer compatible order, update selected symbols]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Provide some helpful information about the devicetree configuration of
our new driver
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct compatible order in examples]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Now that we provide a clock driver for the Reltek SOCs the CPU frequency might
change on demand. This has direct visible effects during operation
- the CEVT 4K timer is no longer a stable clocksource
- after CPU frequencies changes time calculation works wrong
- sched_clock falls back to kernel default interval (100 Hz)
- timestamps in dmesg have only 2 digits left
[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps ...
[ 0.060000] pid_max: default: 32768 minimum: 301
[ 0.070000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.080000] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build
[ 0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, ...
Looking around where we can start the CEVT timer for RTL930X is a good basis.
Initially it was developed as a clocksource driver for the broken timer in that
specific SOC series. Afterwards it was shifted around to the CEVT location,
got SMP enablement and lost its clocksource feature. So we at least have
something to copy from. As the timers on these devices are well understood
the implementation follows this way:
- leave the RTL930X implementation as is
- provide a new driver for RTL83XX devices only
- swap RTL930X driver at a later time
Like the clock driver this patch contains a self contained module that is SOC
independet and already provides full support for the RTL838X, RTL839X and
RTL930X devices. Some of the new (or reestablished) features are:
- simplified initialization routines
- SMP setup with CPU hotplug framework
- derived from LXB clock speed
- supplied clocksource
- dedicated register functions for better readability
- documentation about some caveats
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[remove unused header includes, remove old CONFIG_MIPS dependency, add
REALTEK_ prefix to driver symbol]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Patches for mtk_image supporting newer SoCs have been dropped in the
process of updating mkimage to U-Boot 2022.10. While it is true that
the patches have been merged upstream a while ago, they were not merged
in time to be part of the U-Boot 2022.10 release.
See also commit 537b423d9f ("uboot-mediatek: update to U-Boot 2022.10")
which explicitly mentions that.
Fixes: 6e245777bd ("tools/mkimage: update to 2022.10")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Undo parts of these:
116feb4a1c ipq40xx: remove non-converted network configs
db19efee95 ipq40xx: disable boards not converted to DSA
Reintroduce the DT paths /soc/edma@c080000/gmac{0,1}, because the stock
bootloader has memorized them (instead of following aliases); then plug
the MAC address back in via 05_set_iface_mac_ipq40xx.sh, since the
'local-mac-address' property is no longer in the correct node.
Cc: David Bauer <mail@david-bauer.net>
Cc: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Convert to DSA and enable the MobiPromo CM520-79F device again.
Signed-off-by: Jack Chen <redchenjs@live.com>
Reviewed-by: Robert Marko <robimarko@gmail.com>
This fixes reference clock frequency of RB912. 25 MHz frequency leads
to system clock running too fast, uptime incrementing too fast and
delays (like `sleep 10`) returning too early.
Board has quartz with NSK 3KHAA Z 40 000 marking.
Signed-off-by: Pavel Kamaev <pavel@kamaev.me>
Manufacturer has predetermined mac address values for lan and wan ports.
This change keeps inline with other mt7621 devices mac address allocation
from factory mtd partition.
Example from hexdump output:
0xe000 0x6 (lan) - 0xe006 0x6 (wan)
0000e000 70 b3 d5 10 02 96 70 b3 d5 10 02 95 ff ff ff ff
Previous change had created an overlapping mac address situation as it
would increment by one based on the lan mac address location found in the
factory partition, which would sometimes increment to the same as the
mt7603 wifi chip.
Tested on Unielec u7621-01 model
Signed-off-by: David Bentham <db260179@gmail.com>
The hardware of Nokia A-040W-Q and RAISECOM MSG1500 X.00 are
exactly the same, both of which are customized by operators.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
