If transmissions are done outside of the DSA switch (directly from the CPU
port), the STP state must not block the transmission. Otherwise, STP frames
are not correctly submitted and the STP frames cannot correctly detect
loops before switching a port in the forwarding state.
The same applies for the LLDP frames. These must be submitted independent
of the STP state to identify neighbors or configure POE limits.
It is not necessary to filter specific destination mac addresses because
the transmission was done outside the bridge/switch in the first place. The
transmission is therefore forced.
Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://github.com/openwrt/openwrt/pull/20184
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL930X and RTL931X SoCs support port-based, flow-based, and
RSPAN-based mirroring. Like for other SoCs from the realtek target, only
the port based port mirroring can be exposed using Linux's tc subsystem.
The port_mirror_add() implementation was updated with the following
considerations for RTL93xx SoCs:
* mirrored packets must pass through the TX pipeline of the mirroring
port, so they are subject to configuration such as VLAN tagging,
remarking, and EVC
* when a packet hits both source ports (SPM) and destination port (DPM) of
a mirror group, the egress port traffic will be mirrored
The port_mirror_del() function doesn't require any modifications.
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Co-developed-by: Sven Eckelmann <se@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20264
Signed-off-by: Robert Marko <robimarko@gmail.com>
Instead of using a lot of if-else blocks in the port mirror code, provide
SoC specific function which calculates the SoC specific portions. The
generic part of the port mirroring code can then simply operate on the
calculated register addresses and values.
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20264
Signed-off-by: Robert Marko <robimarko@gmail.com>
Right now the sha256sums are only created for the targets/ folder (i.e.
firmware images) and only the buildbot generates those sha256sums. Instead, let
the build system create the sha256sums directly.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The mlxreg-hotplug platform driver was failing to probe due to a missing
I²C multiplexer dependency. Previously, only kmod-i2c-mux-mlxcpld was
declared, but mlxreg also requires kmod-i2c-mux-reg to initialize its
I²C mux functionality.
Without this dependency, the driver probe was deferred:
[ 24.902331] platform mlxreg-hotplug: deferred probe pending: (reason unknown)
With kmod-i2c-mux-reg added, the probe succeeds and the expected
multiplexed I²C buses are registered:
[ 15.793884] i2c i2c-1: Added multiplexed i2c bus 2
[ 15.799391] i2c i2c-1: Added multiplexed i2c bus 3
[ 15.804830] i2c i2c-1: Added multiplexed i2c bus 4
...
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://github.com/openwrt/openwrt/pull/20274
Signed-off-by: Robert Marko <robimarko@gmail.com>
The FIT loadaddr on RK3308/RK3566/RK3568/RK358x is 0x02000000
instead of 0x02080000, while on RK3576 it's 0x42000000, which is
quite different from the former SoCs and incompatible with current
kernel loadaddr value.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/20041
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When a phy appears after setup has already been attempted, tell netifd
to retry setup for all failed wireless devices.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This can be used by other services to trigger reconfiguration, or detect when
PHY renaming has been performed.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Ensures that renaming is handled properly. For disabled radios, setup is
performed with an empty list of interfaces.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The RTL931x has next to its SPI flash controller a SPI master interface. It
is connected to
* SPI_CS#[1,0]: AH22 , AK22 (aka: GPIO 12, 11)
* SPI_CLK: AL23 (aka: GPIO 8)
* SPI_MISO: AM23 (aka: GPIO 9)
* SPI_MOSI: AL22 (aka: GPIO 10)
It is not the same as the SPI flash controller which uses pins:
* SPI_CS#[1,0]: B24, A24
* SPI_SCLK: A23
* SPI_SDI/SIO0: B21
* SPO_SDO_SIO1: B21
* SPI_SIO2: A22
* SPI_SIO3: B22
* SPI_RSTN: B23
As shown above, the SPI master controller shares its pin with GPIO 8, 9,
10, 11, 12. In some upcoming devices (like the Plasma Cloud PSX28/ESX28),
they will be used for SFP cage signaling. These pins must therefore be
switched manually to the GPIO mode.
The SPI_CTRL0 register provides all necessary configuration to enforce the
GPIO mode of the pins. And until more requirements (and a correct driver)
for the SPI master controller arise, it is therefore possible to use
pinctrl-single to configure it using the devicetree.
Previously the ethernet driver did configure the SPI master controller for
31.25 MHz. It is unknown for which kind of device this was originally made
and what was actually connected there. But this manual write to the
register conflicts potentially with the write of the pinctrl driver to the
same register. Luckily, we don't need this SPI speed configuration in the
ethernet driver. Still, to allow this device an easy migration, the
`spi0-31mhz` configuration was already prepared.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20263
Signed-off-by: Robert Marko <robimarko@gmail.com>
If there is used $(PKG_NAME) in PKG_SOURCE_URL,
then it can not be copy&pasted to the browser's address bar.
Let's remove $(PKG_NAME) and use hardcoded project name
in the PKG_SOURCE_URL
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/20193
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
0782d24 Revert "ptgen: do not create stub partition to fill a gap if gap caused by alignment"
Fixes: #20254
Fixes: c5ece837a3 ("firmware-utils: update to git HEAD")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
c3bf8fd913a4 interface: fix reload for devices that point to vlan aliases
22216cac7c94 bridge: fix reload when ports refer to aliased vlans on another bridge
ecca21ca07dd system: add logging wrappers for basic system functions
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The current SerDes implementation for RTL931x handles 10G-QXGMII via the
"usxgmii" PHY mode. This is not 100% correct because it is not a single
port with 10G (max) but 4 ports with 2.5G each.
To allow setting of the "10g-qxgmii" phy mode, just change the code for now
to use the same codepaths as USXGMII. This has to be cleaned up further
during the SerDes driver rewrites.
Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20239
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Plasma Cloud PSX28 and ESX28 are using RTL8224 as ethernet PHY. This
phy works perfectly fine on PSX8/PSX10 (RTL930x) but failed to establish a link
on rtl931x because the upstream realtek phy driver was not enabled.
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/20239
Signed-off-by: Robert Marko <robimarko@gmail.com>
The u-boot of cmcc_rax3000m_*-ddr3 declares a dependency on
trusted-firmware-a-mt7981-*-ddr3-1866mhz, while actually packages
the normal BL2. This causes build failure if the the non-1866m
variant isn't built.
According to the previous commit, it's intended to use the lower
frequency variant to fix device stability issues. Correct
BL2_DDRTYPE as intended.
Fixes: 028050da69 ("mediatek: CMCC RAX3000Me: fix stability issues")
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
APK kindly stores the mtime of each containing file in created packages,
breaking reproducibility. As a fix, touch all files of the package with the
timestamp of PKGSOURCE_DATE_EPOCH, which contains the timestamp based on the
last package modification.
Over at OPKG, something similar is done by setting mtime in the tar command,
see the `ipkg-build` script.
To tackle this in APK directly, some changes are suggested. However until this
is merged, we should fix it downstream.
https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/348
Signed-off-by: Paul Spooren <mail@aparcar.org>
