1
0
Fork 0
forked from mirror/openwrt
Commit graph

839 commits

Author SHA1 Message Date
Markus Stockhausen
2c501d9db9 realtek: rtl930x: convert Hasivo S1100W to lzma only.
The current build recipe creates a lzma based initramfs and
a gzip based sysupgrade (installation) image. No need to
use different compression methods. Use lzma for both.

Tested-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19669
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 15:22:52 +02:00
Jan Hoffmann
2a9f0db76f realtek: extend SoC information
Add SoC revision, CPU part number, and a flag for engineering samples to
the rtl83xx_soc_info structure.

Also extend the system type string to include this information.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 13:41:51 +02:00
Jan Hoffmann
368dab7c7a realtek: move and clean up CHIP_INFO register definitions
Move the definitions to mach-rtl83xx.h, so they can be used during init
to read more detailed SoC information. Also rename the RTL931X register,
as it has the same address on all RTL93xx.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 13:41:51 +02:00
Jan Hoffmann
d469690b83 realtek: simplify SoC detection
Read model name from the register instead of using hard-coded values.

Also remove detection of the unsupported Realtek ESW/SSW SoCs. The Fast
Ethernet variants of the Maple and Cypress series stay for now, but are
moved to the RTL8380/RTL8390 families.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19653
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 13:41:51 +02:00
Jonas Jelonek
bd861f05cc realtek: use lzma recipe for TP-Link TL-ST1008F v2.0
Use the lzma recipe for the device for both initramfs and sysupgrade to
save some flash space due to smaller image. U-Boot build on this device
has native lzma support.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19657
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 10:29:15 +02:00
Markus Stockhausen
e0ba4cf086 realtek: rtl930x: move serdes functions over to mdio bus
The migration of the RTL930x mdio/serdes access functions over to the
mdio bus is a little more complicated than for RTL83xx. There are several
places where the serdes is accessed directly. So do it in two steps. With
this first step:

- use the rtmdio prefix for the serdes reader/writer functions
- move the functions over to the bus (inside the ethernet driver)
- Adapt all callers.

This is not only a copy/paste but the serdes access will be hardened too.
For this:

- put a mutex around the read/write functions because we have only
  indirect register access through a mdio style bus.
- Verify input values to avoid data mess.

Tested-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Jan Hoffmann <jan@3e8.eu>
Tested-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19662
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-06 10:10:58 +02:00
Markus Stockhausen
5584e2f6a7 realtek: rtl930x: enable SMP
Like RTL839x the RTL930x SoCs have multithreading built in.
Activate it in the kernel configuration.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19624
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-04 16:01:49 +02:00
Markus Stockhausen
afa4662ed0 realtek: RTL839x: reorganize mdio functions and SerDes register layout
The RTL839x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver).

Additionally provide a consistent SerDes register access through the
mdio bus. Until now when a SerDes directly drives a SFP module there
is no clear rule of how to handle its register set that consists of
two parts:

- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after

The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.

Adapt the bus to the new consistent phy interface that mixes the
SerDes register set like classic Realtek phys do it.

- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
  registers 16-23 according to the page select register (31).

That gives a register mapping as follows:

+-----------------------+-----------------------+---------------+-------------+
| reg 0x00-0x0f         | reg 0x10-0x17         | reg 0x18-0x1e | reg 0x1f    |
+-----------------------+-----------------------+---------------+-------------+
| SerDes fiber page (3) | real SerDes registers | zero          | SerDes page |
| registers 0 - 15      | in packages of 8      |               | select reg  |
+-----------------------+-----------------------+---------------+-------------+

Example to make it as clear as possible.

SerDes registers on a RTL839x show

Page / Reg   | 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B ...
-------------+----------------------------------------------------------------
0 - SDS      | 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248 0000 0F80 0000 ...
1 - SDS_EXT  | 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA 8C64 00C3 1482 ...
2 - FIB      | 1140 6189 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
3 - FIB_EXT  | 1140 6109 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...

This translates to this phy layout

             | SerDes fiber registers  normal SerDes registers  zero     p.sel
Page / Reg   | 0x00 0x01 0x02 0x03 ... 0x10 0x11 0x12 0x13 ...  0x18 ... 0x1f
-------------+---------------------------------------------------------------
0            | 1140 6189 001C CA40 ... 0C03 0F00 7060 7106 ...  0000 ... 0000
1            | 1140 6189 001C CA40 ... 5248 0000 0F80 0000 ...  0000 ... 0001
...
4            | 1140 6189 001C CA40 ... 0000 0000 85FA 8C6D ...  0000 ... 0004
...

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19634
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-04 10:43:17 +02:00
Joe Holden
c95a08b1c5 realtek: Zyxel GS1900-48 dts fixes
* Use SDS for phy 48/49
 * Use correct link/phy settings for SFP ports
 * Remove read-only flag from u-boot env so fw_setenv actually works

Signed-off-by: Joe Holden <jwh@zorins.us>
Link: https://github.com/openwrt/openwrt/pull/19596
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-03 15:33:36 +02:00
Markus Stockhausen
9dddc0bed0 realtek: mdio: RTL838x: create new SerDes phy register layout
When a SerDes directly drives a SFP module there is no clear rule of
how to handle its register set that consists of two parts:

- c22 phy registers 0-15 live in the fiber page (2) of the SerDes
- other SerDes specific registers exist in pages before and after

The mdio bus and other SerDes functions are a wild mix of directly
looking into page 2 or just using self defined methods to access
data.

Provide a consistent phy interface that mixes the SerDes register
set like classic Realtek phys do it.

- Use register 31 as page select (already in the bus)
- Always keep the common registers 0-15 in place and read fiber page
- Map the SerDes internal registers into the upper vendor specific
  registers 16-23 according to the page select register (31).

That gives a register mapping as follows:

+-----------------------+-----------------------+---------------+-------------+
| reg 0x00-0x0f         | reg 0x10-0x17         | reg 0x18-0x1e | reg 0x1f    |
+-----------------------+-----------------------+---------------+-------------+
| SerDes fiber page (3) | real SerDes registers | zero          | SerDes page |
| registers 0 - 15      | in packages of 8      |               | select reg  |
+-----------------------+-----------------------+---------------+-------------+

Example to make it as clear as possible.

SerDes registers on a RTL838x show

Page / Reg   | 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B ...
-------------+----------------------------------------------------------------
0 - SDS      | 0C03 0F00 7060 7106 074D 0EBF 0F0F 0359 5248 0000 0F80 0000 ...
1 - SDS_EXT  | 0000 0000 85FA 8C6D 5CCC 0000 20D8 0003 79AA 8C64 00C3 1482 ...
2 - FIB      | 1140 6189 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...
3 - FIB_EXT  | 1140 6109 001C CA40 01A0 0000 0000 0004 0000 0000 0000 0000 ...

This translates to this phy layout

             | SerDes fiber registers  normal SerDes registers  zero     p.sel
Page / Reg   | 0x00 0x01 0x02 0x03 ... 0x10 0x11 0x12 0x13 ...  0x18 ... 0x1f
-------------+---------------------------------------------------------------
0            | 1140 6189 001C CA40 ... 0C03 0F00 7060 7106 ...  0000 ... 0000
1            | 1140 6189 001C CA40 ... 5248 0000 0F80 0000 ...  0000 ... 0001
...
4            | 1140 6189 001C CA40 ... 0000 0000 85FA 8C6D ...  0000 ... 0004

For now just do it for RTL838x devices.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19604
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-02 11:42:49 +02:00
Markus Stockhausen
40d70c9c81 realtek: dsa: do not open code PHY access
The DSA has a link to the MDIO bus and already uses the read/write functions
that are provided. In parallel the dsa_switch_ops structure provides an
interface for phy_read and phy_write. These are still open-coded and sadly
circumvent the bus. Simplify the implementation and avoid inconsistencies by
reusing the existing bus infrastructure.

Additionally, remove two unused MMD header definitions as a quick win.

Reported-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19548
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-31 22:00:25 +02:00
Harshal Gohel
960ad676c1 realtek: rtl931x: Fix printing of port matrix
The function rtl93xx_setup() is called by both RTL930x and RTL931x. But
only the RTL930x specific function to print port matrix was called.
Unfortuntaly, RTL931x needs a different function to access the correct
registers to retrieve the port matrix information.

It is therefore necessary differentiate in rtl93xx_setup between the
SoC families before calling the appropriate function.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19572
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-31 21:59:24 +02:00
Harshal Gohel
b61fda1035 realtek: rtl931x: Update irq mask to cover all ports
The RTL931x has 56 (0-55) non-CPU ports. To receive updates about the port
state, it is therefore necessary to enable the interrupts for all these
ports.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19572
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-31 21:59:23 +02:00
Harshal Gohel
f51b54bc95 realtek: rtl931x: Fix traffic on upper ports
* traffic isolation tables are different between rtl930x and rtl931x
* traffic_enable/disable/get/set functions span multiple columns in the
  rtl931x as a result, previous implementation would only enable traffic
  in some ports.

traffic_enable/disable and traffic_set/get should now work on all ports and
not just the initial 32

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19572
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-31 21:59:23 +02:00
Harshal Gohel
656312f9b7 realtek: rtl930x: Fix bringup of SFP modules
The commit d2108c2c58 ("realtek: enhance RTL930x SerDes/PLL/CMU
interoperability") removed a couple of commands for the bringup code.
One of these commands was necessary to bring up SFP modules correctly. This
one can also be found in the RTLSDK [1].

It is currently not 100% clear what this command does. But if it works
similar to the RTL8295 [2,3] (RTL8295_SDS0_ANA_MISC_REG00_REG), we could
assume that it could be the RX_ON and RX_EN bits.

[1] 0e2e45341a/loader/u-boot-2011.12/board/Realtek/switch/sdk/src/dal/longan/dal_longan_sds.c (L1104)
[2] https://svanheule.net/realtek/mango/register/serdes_indrt_access_ctrl
[3] 54589ff0af/sources/rtk-dms1250/include/hal/phy/rtl8295_reg_def.h (L7726)

Reported-by: Jan Fuchs <jf@simonwunderlich.de>
Fixes: d2108c2c58 ("realtek: enhance RTL930x SerDes/PLL/CMU interoperability")
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19582
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-31 21:57:28 +02:00
Markus Stockhausen
9b5d055076 realtek: add NAND hardware description to RTL93xx
Include the NAND specs into the DTS. It is unclear which devices
really need it. Keep it disabled for now. As the SoC register area
is defined too small until now, increase the size to an appropriate
value.

If enabled one can see the following log messages (e.g. Linksys
LGS328C or LGS352C).

[    1.206600] spi-nand spi1.0: Macronix SPI NAND was found.
[    1.212795] spi-nand spi1.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[    1.222217] 3 fixed-partitions partitions found on MTD device spi1.0
[    1.229466] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[    1.236617] OF: Bad cell count for /soc/spi@1a400/flash@0/partitions
[    1.244164] Creating 3 MTD partitions on "spi1.0":
[    1.249620] 0x000000000000-0x000004000000 : "ubifs"
[    1.423593] 0x000004000000-0x000005e00000 : "firmware"
[    1.738268] mtdsplit_uimage: no uImage found in "firmware"
[    1.744577] 0x000005e00000-0x000007c00000 : "runtime2"

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19583
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-30 23:22:24 +02:00
Markus Stockhausen
41b0340ff0 realtek: backport NAND driver for RTL93xx
RTL93xx devices have a NAND controller built in. Upstream already
has a driver in place. Include it downstream. Activate it in the
RTL93xx builds and disable it for the RTL83xx builds.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19583
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-30 23:22:24 +02:00
Harshal Gohel
d802e6310a realtek: rtl931x: Support enable/disable SMI Polling for SerDes ports
During PHY matching, the SMI polling must be disabled to avoid conflicts
during the complex detection routine. Only after this finished, SMI polling
is allowed again.

This was implemented for all realtek families besides RTL931x.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19603
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-30 12:48:26 +02:00
Harshal Gohel
848887b491 realtek: rtl931x: Fix SDS field modifications
A RTL930x function to read the value from an SDS register must not used on
an RTL931x SoC. Doing it with rtl930x_read_sds_phy() would corrupt the
written results when only parts of the bits are written.

Fixes: 7026084066 ("realtek: Add SDS configuration routines for the RTL93XX platforms")
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19603
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-30 12:48:26 +02:00
Markus Stockhausen
b1597c9ad4 realtek: convert RTL838x toolchain to 24kc
The Realtek RTL838x devices have a MIPS 4Kec core. This has a very simple pipeline.
OpenWrt uses CPU_TYPE:=4kec to honour this and adds a dedicated toolchain with
some GB of extra space. There would be no problem if that toolchain would do what
it is expected to do. Looking at the build process one can see:

during kernel builds:
  ps -ef | grep mtune
  ... -march=mips32r2 -mtune=34kc ...

during package builds
  ps -ef | grep mtune
  ... -mips32r2 -mtune=4kec ...

So the kernel is optimized for the wrong cpu type while the applications fit fine.
Explanation for this is the generic/308-mips32r2_tune.patch. This forces kernel
builds to -mtune=34kc. Nevertheless everything runs fine since years on the RTL838x
targets.

It does not make sense to provide a dedicated 4kec toolchain for this mess. So
change the setup as follows:

- switch CPU type to mips24kc for RTL838x -> This drops one toolchain and saves space
- Add a RTl838x specific mtune=4kec patch -> Builds kernel with the proper setting

Downside is packages will be built with -mtune=24kc. So a look at a simple benchmark
should give insight if this has really a big impact. See numbers attached. To sum it
up in two sentences

- All non RSA benchmarks are within expectation
- RSA benchmarks show large deviations (before and after)

The normal usecase for these switches is definetly not a CPU intensive workload
so this is ok for now.

Before: kernel 6.12 (mtune=34kc) + apps (mtune=4kec)

root@OpenWrt:/usr/bin# ./wolfssl-benchmark
------------------------------------------------------------------------------
 wolfSSL version 5.7.6
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RNG                          5 MiB took 1.426 seconds,    3.507 MiB/s
AES-128-CBC-enc              5 MiB took 1.178 seconds,    4.243 MiB/s
AES-128-CBC-dec              5 MiB took 1.171 seconds,    4.270 MiB/s
AES-192-CBC-enc              5 MiB took 1.307 seconds,    3.824 MiB/s
AES-192-CBC-dec              5 MiB took 1.311 seconds,    3.815 MiB/s
AES-256-CBC-enc              5 MiB took 1.447 seconds,    3.455 MiB/s
AES-256-CBC-dec              5 MiB took 1.421 seconds,    3.519 MiB/s
AES-128-GCM-enc              5 MiB took 3.772 seconds,    1.325 MiB/s
AES-128-GCM-dec              5 MiB took 3.756 seconds,    1.331 MiB/s
AES-192-GCM-enc              5 MiB took 3.939 seconds,    1.269 MiB/s
AES-192-GCM-dec              5 MiB took 3.932 seconds,    1.272 MiB/s
AES-256-GCM-enc              5 MiB took 4.043 seconds,    1.237 MiB/s
AES-256-GCM-dec              5 MiB took 4.033 seconds,    1.240 MiB/s
GMAC Default                 2 MiB took 1.056 seconds,    1.895 MiB/s
AES-128-CTR                  5 MiB took 1.195 seconds,    4.185 MiB/s
AES-192-CTR                  5 MiB took 1.319 seconds,    3.791 MiB/s
AES-256-CTR                  5 MiB took 1.460 seconds,    3.425 MiB/s
AES-CCM-enc                  5 MiB took 2.279 seconds,    2.194 MiB/s
AES-CCM-dec                  5 MiB took 2.273 seconds,    2.200 MiB/s
ARC4                        20 MiB took 1.226 seconds,   16.315 MiB/s
CHACHA                      15 MiB took 1.001 seconds,   14.982 MiB/s
CHA-POLY                    15 MiB took 1.440 seconds,   10.416 MiB/s
3DES                         5 MiB took 4.364 seconds,    1.146 MiB/s
MD5                         25 MiB took 1.034 seconds,   24.173 MiB/s
POLY1305                    35 MiB took 1.015 seconds,   34.467 MiB/s
SHA                         25 MiB took 1.127 seconds,   22.183 MiB/s
SHA-256                     10 MiB took 1.104 seconds,    9.056 MiB/s
SHA-384                      5 MiB took 1.324 seconds,    3.775 MiB/s
SHA-512                      5 MiB took 1.325 seconds,    3.774 MiB/s
SHA-512/224                  5 MiB took 1.319 seconds,    3.791 MiB/s
SHA-512/256                  5 MiB took 1.333 seconds,    3.751 MiB/s
AES-128-CMAC                 5 MiB took 1.145 seconds,    4.366 MiB/s
AES-256-CMAC                 5 MiB took 1.413 seconds,    3.539 MiB/s
HMAC-MD5                    25 MiB took 1.034 seconds,   24.186 MiB/s
HMAC-SHA                    25 MiB took 1.122 seconds,   22.272 MiB/s
HMAC-SHA256                 10 MiB took 1.104 seconds,    9.059 MiB/s
HMAC-SHA384                  5 MiB took 1.329 seconds,    3.762 MiB/s
HMAC-SHA512                  5 MiB took 1.323 seconds,    3.778 MiB/s
PBKDF2                       1 KiB took 1.018 seconds,    1.136 KiB/s
RSA     2048  key gen         1 ops took 15.547 sec, avg 15547.322 ms, 0.064 ops/sec
RSA     3072  key gen         1 ops took 66.131 sec, avg 66131.134 ms, 0.015 ops/sec
RSA     4096  key gen         1 ops took 563.611 sec, avg 563611.230 ms, 0.002 ops/sec
RSA     2048   public       200 ops took 1.403 sec, avg 7.015 ms, 142.542 ops/sec
RSA     2048  private       100 ops took 39.099 sec, avg 390.991 ms, 2.558 ops/sec
DH      2048  key gen        14 ops took 1.009 sec, avg 72.094 ms, 13.871 ops/sec
DH      2048    agree       100 ops took 15.714 sec, avg 157.139 ms, 6.364 ops/sec
ECC   [      SECP256R1]   256  key gen       100 ops took 5.590 sec, avg 55.901 ms, 17.889 ops/sec
ECDHE [      SECP256R1]   256    agree       100 ops took 5.555 sec, avg 55.554 ms, 18.001 ops/sec
ECDSA [      SECP256R1]   256     sign       100 ops took 5.705 sec, avg 57.048 ms, 17.529 ops/sec
ECDSA [      SECP256R1]   256   verify       100 ops took 4.396 sec, avg 43.963 ms, 22.746 ops/sec
CURVE  25519  key gen       320 ops took 1.000 sec, avg 3.127 ms, 319.841 ops/sec
CURVE  25519    agree       400 ops took 1.214 sec, avg 3.034 ms, 329.546 ops/sec
Benchmark complete

After: kernel 6.12 (mtune=4kec) + apps (mtune=24kc)

root@OpenWrt:~# wolfssl-benchmark
------------------------------------------------------------------------------
 wolfSSL version 5.7.6
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1048576, min 1.0 sec each)
RNG                          5 MiB took 1.428 seconds,    3.501 MiB/s
AES-128-CBC-enc              5 MiB took 1.174 seconds,    4.258 MiB/s
AES-128-CBC-dec              5 MiB took 1.162 seconds,    4.301 MiB/s
AES-192-CBC-enc              5 MiB took 1.307 seconds,    3.826 MiB/s
AES-192-CBC-dec              5 MiB took 1.313 seconds,    3.809 MiB/s
AES-256-CBC-enc              5 MiB took 1.432 seconds,    3.491 MiB/s
AES-256-CBC-dec              5 MiB took 1.426 seconds,    3.506 MiB/s
AES-128-GCM-enc              5 MiB took 3.761 seconds,    1.329 MiB/s
AES-128-GCM-dec              5 MiB took 3.748 seconds,    1.334 MiB/s
AES-192-GCM-enc              5 MiB took 3.918 seconds,    1.276 MiB/s
AES-192-GCM-dec              5 MiB took 3.922 seconds,    1.275 MiB/s
AES-256-GCM-enc              5 MiB took 4.019 seconds,    1.244 MiB/s
AES-256-GCM-dec              5 MiB took 4.014 seconds,    1.246 MiB/s
GMAC Default                 2 MiB took 1.052 seconds,    1.900 MiB/s
AES-128-CTR                  5 MiB took 1.189 seconds,    4.205 MiB/s
AES-192-CTR                  5 MiB took 1.315 seconds,    3.804 MiB/s
AES-256-CTR                  5 MiB took 1.455 seconds,    3.436 MiB/s
AES-CCM-enc                  5 MiB took 2.257 seconds,    2.215 MiB/s
AES-CCM-dec                  5 MiB took 2.269 seconds,    2.204 MiB/s
ARC4                        15 MiB took 1.062 seconds,   14.124 MiB/s
CHACHA                      15 MiB took 1.008 seconds,   14.880 MiB/s
CHA-POLY                    15 MiB took 1.461 seconds,   10.266 MiB/s
3DES                         5 MiB took 4.347 seconds,    1.150 MiB/s
MD5                         25 MiB took 1.029 seconds,   24.291 MiB/s
POLY1305                    35 MiB took 1.024 seconds,   34.181 MiB/s
SHA                         25 MiB took 1.115 seconds,   22.418 MiB/s
SHA-256                     10 MiB took 1.154 seconds,    8.664 MiB/s
SHA-384                      5 MiB took 1.345 seconds,    3.718 MiB/s
SHA-512                      5 MiB took 1.343 seconds,    3.723 MiB/s
SHA-512/224                  5 MiB took 1.350 seconds,    3.703 MiB/s
SHA-512/256                  5 MiB took 1.345 seconds,    3.718 MiB/s
AES-128-CMAC                 5 MiB took 1.143 seconds,    4.376 MiB/s
AES-256-CMAC                 5 MiB took 1.405 seconds,    3.559 MiB/s
HMAC-MD5                    25 MiB took 1.027 seconds,   24.334 MiB/s
HMAC-SHA                    25 MiB took 1.112 seconds,   22.490 MiB/s
HMAC-SHA256                 10 MiB took 1.096 seconds,    9.125 MiB/s
HMAC-SHA384                  5 MiB took 1.344 seconds,    3.721 MiB/s
HMAC-SHA512                  5 MiB took 1.347 seconds,    3.712 MiB/s
PBKDF2                       1 KiB took 1.012 seconds,    1.142 KiB/s
RSA     2048  key gen         1 ops took 27.136 sec, avg 27136.046 ms, 0.037 ops/sec
RSA     3072  key gen         1 ops took 39.922 sec, avg 39922.464 ms, 0.025 ops/sec
RSA     4096  key gen         1 ops took 519.483 sec, avg 519482.959 ms, 0.002 ops/sec
RSA     2048   public       200 ops took 1.398 sec, avg 6.989 ms, 143.073 ops/sec
RSA     2048  private       100 ops took 40.412 sec, avg 404.121 ms, 2.475 ops/sec
DH      2048  key gen        14 ops took 1.033 sec, avg 73.764 ms, 13.557 ops/sec
DH      2048    agree       100 ops took 16.401 sec, avg 164.009 ms, 6.097 ops/sec
ECC   [      SECP256R1]   256  key gen       100 ops took 5.583 sec, avg 55.830 ms, 17.912 ops/sec
ECDHE [      SECP256R1]   256    agree       100 ops took 5.555 sec, avg 55.549 ms, 18.002 ops/sec
ECDSA [      SECP256R1]   256     sign       100 ops took 5.703 sec, avg 57.032 ms, 17.534 ops/sec
ECDSA [      SECP256R1]   256   verify       100 ops took 4.203 sec, avg 42.030 ms, 23.792 ops/sec
CURVE  25519  key gen       315 ops took 1.001 sec, avg 3.176 ms, 314.822 ops/sec
CURVE  25519    agree       400 ops took 1.244 sec, avg 3.110 ms, 321.579 ops/sec
Benchmark complete

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19117
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-30 10:34:25 +02:00
Colton Pawielski
9c26d14489 realtek: add support for Vimin VM-S100-0800MS
Vimin VM-S100-0800MS is an 8 port Multi-Gig switch, based on RTL9303.
Ported from XikeStor SKS8300-8X with changes to support different u-boot
build.

Specification:

- SoC             : Realtek RTL9303
- RAM             : DDR3 512 MiB
- Flash           : SPI-NOR 16 MiB (Winbond W25Q128JVSQ)
- Ethernet        : 8x 1/2.5/10 Gbps (SFP+)
- LEDs/Keys (GPIO): 0x/1x
- UART            : "Console" port on the front panel
  - type          : RS-232C
  - connector     : RJ-45
  - settings      : 115200n8
- Power           : AC100-240V 50/60Hz

Flash instruction using initramfs image:

 1. Prepare TFTP server with an IP address "192.168.1.111"
 2. Connect your PC to Port1 on VM-S100-0800MS
 3. Power on VM-S100-0800MS and interrupt boot by pressing Esc
 4. Enable Port1 with the following commands

    rtk 10g 0 fiber1g (or fiber10g if 10GBase-*R, dac300cm for DAC cable)
    rtk ext-devInit 0
    rtk ext-pinSet 2 0

    Note: the last command sets tx-disable to low

 7. Download initramfs image from TFTP server

    tftpboot 0x82000000 <image name>

 8. Boot with the downloaded image

    bootm

 9. On the initramfs image, backup the stock firmware if needed
10. Upload (or download) sysupgrade image to the device
11. Erase "firmware" partition to cleanup JFFS2 of stock FW

    mtd erase firmware

12. Perform sysupgrade with the sysupgrade image
13. Wait ~120 sec to complete flashing

Reverting to stock firmware:
 1. Prepare by downloading the stock firmware. Vimin doesn't have
    the firmware on their website, tested using firmware for shared
    hardware Nicgiga S100-0800S-M.
    Filename: vmlinux-nicgiga-S100-0800S-M-241126EN.bix

 2. Prepare TFTP server with an IP address "192.168.1.111"
 3. Connect your PC to Port1 on VM-S100-0800MS
 4. Power on VM-S100-0800MS and interrupt boot by pressing Esc
 5. Enable Port1 with the following commands

    rtk 10g 0 fiber1g (or fiber10g if 10GBase-*R, dac300cm for DAC cable)
    rtk ext-devInit 0
    rtk ext-pinSet 2 0

    Note: the last command sets tx-disable to low

 6. Download initramfs image from TFTP server

    tftpboot 0x82000000 <image name>

 7. Boot with the downloaded image

    bootm

 8. Under Management -> Firmware -> Upgrade/Backup, upload bix file.
 9. Reboot device

Signed-off-by: Colton Pawielski <cepawiel@mtu.edu>
Link: https://github.com/openwrt/openwrt/pull/19477
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-28 23:37:39 +02:00
Andrew LaMarche
ed7d62caf2 realtek: add support for Hasivo S1100W-8XGT-SE switch
This commit adds support for Hasivo S1100W-8XGT-SE switch.

Device specification
--------------------
SoC Type:	RTL9303
RAM:		Samsung K4B461646E-BYKO (512MB)
Flash:		Fudan FM25Q128A (16 MB)
Ethernet:	8x 10G via 2x RTL8264 PHY
LEDs:		2 LEDs, 1 power green, 1 system green
Button:		Reset
USB ports:	None
Bootloader:	Realtek U-Boot - U-Boot 2011.12.(3.6.6.55087) (Nov 13 2022 - 14:37:31)
Fan:            2 fans controlled by STC8G1K08 TSOP-20 microcontroller

Note: The fan appears to operate the same irrespective of the running
firmware. The STC9G1K08 is likely operating independently.

To explore the stock vendor firmware, there are 2 avenues to gain root
access. This is not necessary to install OpenWrt, but is here for
reference.

Root access via serial
----------------------
1. ctrl+t
2. password: switchrtk
3. press 's' for shell

Root access via SSH
-------------------
1. ctrl+t
2. password: switchrtk
3. sys command sh
4. log in with your username+password
5. ctrl+t
6. password: switchrtk
7. press 's' for shell

Credit to https://forum.openwrt.org/t/hasivo-switches/151758/174 for rooting instructions.

Installing OpenWrt
------------------
1. Connect to UART. UART requires soldering an RJ45 connector to the
   console footprint on the board. The header is on the top right of
   this image: 4d2ab97fad.jpeg
2. Set computer IP to 192.168.0.111.
3. Enter bootloader by pressing esc key during boot.
4. Enter password 'Hs2021cfgmg'.
5. Type 'XXXX'.
6. setenv bootcmd 'rtk network on; bootm 0xb4300000'
7. saveenv
8. rtk network on
9. tftpboot 0x84f00000 <openwrt-initramfs>
10. bootm 0x84f00000

Now you can copy over the sysupgrade image and install.

Credit to
https://forum.openwrt.org/t/hasivo-switches/151758/22?u=andrewjlamarche
for u-boot console access instructions.

Signed-off-by: Andrew LaMarche <andrewjlamarche@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17137
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-27 18:50:03 +02:00
Jan Hoffmann
ec69736270 realtek: implement polling for hardware counters
Maintain 64 bit counters by polling the hardware counters and adding up
the differences. Polling needs to happen just often enough to catch
every single overflow.

As we now have non-overflowing counters now, we can safely calculate
composite counters without getting weird results on overflow. Use this
to follow RFC 3635 more accurately by mapping the hardware counters to
the proper counters, while taking into account hardware quirks as best
as possible.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-27 16:46:20 +02:00
Jan Hoffmann
fa63a5365e realtek: implement get_stats64
By default, the network interface stats are based on software counters,
which only consider traffic from and to the CPU. Implementing the
get_stats64 method allows to report the full hardware counters instead.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-27 16:46:20 +02:00
Jan Hoffmann
e27e695978 realtek: use more specific APIs for ethtool stats where possible
The kernel offers several alternatives to get_ethtool_stats which allow
to report some stats in a more structured way. Use them where possible.

Ideally, we should follow RFC 3635 to translate the hardware counters to
the supported frame and octet counters. However, this is not feasible,
as some of the counters are 32-bit only (so it would produce incorrect
results as soon as one of them overflows).

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-27 16:46:19 +02:00
Jan Hoffmann
831c1cd864 realtek: fix ethtool stats for RTL839x and RTL930x
The MIB registers contain different stats depending on the SoC, and for
RTL930x some stats are in an additional register.

Create separate MIB descs for each SoC to implement this. Also make
reading 64-bit counters more robust, by protecting against an overflow
of the lower 32 bits during the read.

RTL931x remains unsupported, because it uses a table and thus requires
a separate implementation.

While we are at it, rename structs/functions to use the rtldsa prefix.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/18415
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-27 16:46:19 +02:00
Markus Stockhausen
21d3722c40 realtek: don't disable MIPS counter on secondary VPEs
After observation that timer interrupt 7 always fires on secondary VPEs
the counter was disabled in the startup code. This is a bad idea when
building the kernel with jitterentropy. To generate entropy it makes use
of function random_get_entropy(). On MIPS architecture this simply reads
the counter register on the current core. With a disabled counter it
always returns the same value and the entropy initialization stalls the
core if it runs on a secondary VPE. See backtrace

[   21.736246] rcu: INFO: rcu_sched self-detected stall on CPU
[   21.736246] rcu: INFO: rcu_sched self-detected stall on CPU
[   21.748594] rcu:     1-....: (2100 ticks this GP) idle=064c/1/0x40000002 softirq=7/7 fqs=1050
[   21.748594] rcu:     1-....: (2100 ticks this GP) idle=064c/1/0x40000002 softirq=7/7 fqs=1050
[   21.766871] rcu:     (t=2102 jiffies g=-1187 q=25 ncpus=2)
[   21.766871] rcu:     (t=2102 jiffies g=-1187 q=25 ncpus=2)
[   21.778429] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.39 #482
[   21.778429] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.39 #482
[   21.778461] Hardware name: Zyxel GS1900-48
[   21.778461] Hardware name: Zyxel GS1900-48
...
[   21.779757] [<8029b968>] jent_measure_jitter+0xc8/0x10c
[   21.779757] [<8029b968>] jent_measure_jitter+0xc8/0x10c
[   21.779779] [<8029b9e8>] jent_gen_entropy+0x3c/0xb0
[   21.779779] [<8029b9e8>] jent_gen_entropy+0x3c/0xb0
[   21.779800] [<8029bcc0>] jent_entropy_collector_alloc+0x104/0x118
[   21.779800] [<8029bcc0>] jent_entropy_collector_alloc+0x104/0x118
[   21.779822] [<8029bd6c>] jent_entropy_init+0x4c/0x2ec
[   21.779822] [<8029bd6c>] jent_entropy_init+0x4c/0x2ec
[   21.779844] [<8086f184>] jent_mod_init+0x58/0xac
[   21.779844] [<8086f184>] jent_mod_init+0x58/0xac
[   21.779865] [<80100200>] do_one_initcall+0x70/0x250
[   21.779865] [<80100200>] do_one_initcall+0x70/0x250
[   21.779883] [<8085c018>] kernel_init_freeable+0x1f0/0x280
[   21.779883] [<8085c018>] kernel_init_freeable+0x1f0/0x280
[   21.779905] [<8067cba4>] kernel_init+0x20/0xb0
[   21.779905] [<8067cba4>] kernel_init+0x20/0xb0
[   21.779926] [<80101158>] ret_from_kernel_thread+0x14/0x1c
[   21.779926] [<80101158>] ret_from_kernel_thread+0x14/0x1c

This bit of entropy is helpful on these low end devices. Reenable the
counter and simply disable the interrupt.

Fixes: b7aab19585 ("realtek: SMP handling of R4K timer interrupts")
Reported-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19499
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-26 15:51:23 +02:00
Markus Stockhausen
a3bfb67072 realtek: mdio: RTL838x: move functions over to bus
The mdio bus functions are still split between ethernet and dsa driver.
Before moving everthing out to a separate mdio driver we decided to
collect everything in the ethernet driver with the rtmdio prefix.
Take over the remaining RTL838x functions.

Remark: This is more or less a copy/paste with function renaming. As
there are still some consumers in the DSA driver the definitions and
inclusions must be flipped.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19484
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-26 15:46:31 +02:00
Markus Stockhausen
ded18a3683 realtek: dsa: enhance pcs_get_state() for RTL83xx
Currently the SerDes driven SFP ports give strange ethtool readings
on RTL83xx devices. Especially duplex and speed are shown even if
no link is up and running. That leads to confusion because the MAC
reports arbitrary values.

Enhance the readout by refactoring the pcs_get_state() function.
Calculate speed/duplex/pause only if link is detected. Additionally
add reporting of 10G for SFP+ on RTL839x.

ethtool for empty SFP cage before/after

root@OpenWrt:~# ethtool lan9
Settings for lan9:
        Supported ports: [ MII ]
        Supported link modes:   1000baseT/Full
                                1000baseKX/Full
                                1000baseX/Full
                                1000baseT1/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseT/Full
                                1000baseKX/Full
                                1000baseX/Full
                                1000baseT1/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

root@OpenWrt:~# ethtool lan9
Settings for lan9:
        Supported ports: [ MII ]
        Supported link modes:   1000baseT/Full
                                1000baseKX/Full
                                1000baseX/Full
                                1000baseT1/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseT/Full
                                1000baseKX/Full
                                1000baseX/Full
                                1000baseT1/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

ethtool with inserted but NOT connected 1G module before/after

root@OpenWrt:~# ethtool lan9
Settings for lan9:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseX/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

root@OpenWrt:~# ethtool lan9
Settings for lan9:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseX/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: no

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19524
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-26 13:23:42 +02:00
Leo Barsky
b6276e33eb kernel: bump 6.12 to 6.12.40
Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.12.40
Removed upstreamed patches:
   generic/pending-6.12/680-net-fix-TCP-UDP-fraglist-GRO.patch
   generic/pending-6.12/802-nvmem-u-boot-env-align-endianness-of-crc32-values.patch
1- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.40&id=7c532f222361191fe228e54c5d3e0026fef8a5a0
2- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.12.40&id=c29a2328af96338d327cd851803338423c6f07a1
All other patches auto-refreshed.

Signed-off-by: Leo Barsky <leobrsky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/19514
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-26 01:00:09 +02:00
Jan Hoffmann
15a4d621d8 realtek: actually enable 2500Base-X
The SerDes setup function needs to be called to make 2500Base-X work.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/19517
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-25 23:52:49 +02:00
Markus Stockhausen
19bc6e8c7f realtek: phy: add basic RTL8218B setup
On some devices (like ZyXEL GS1920) the phys are not initialized and patched
by the bootloader. This is done through the vendor SDK when the software
starts. To make these devices usable too, provide the most basic setup
sequence for the RTL8218B.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19491
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-24 00:44:02 +02:00
Markus Stockhausen
9533e2e574 realtek: dsa: relax capability checks for 2.5G modes
The driver currently uses two checks to verify the capabilities. These
are ..._phylink_get_caps() and ..._pcs_validate(). For RTL930x these
must allow 2.5G modes. Enhance that as follows:

Add 2500BASEX to phylink_get_caps(). Sort the interfaces alphabetically
and rename the function to the new prefix. IMPORTANT REMARK! Until now
this function allowed the XGMII mode (10G only parallel interface) that
was somehow mixed with the Realtek proprietary mode XSGMII (10G SGMII).
Remove it to avoid further confusion.

Looking upstream pcs_validate() is used less and less. There are only
2 consumers left in 6.16 and the calling location reads:

	/* Validate the link parameters with the PCS */
	if (pcs->ops->pcs_validate) {
		ret = pcs->ops->pcs_validate(pcs, supported, state);
		if (ret < 0 || phylink_is_empty_linkmode(supported))
			return -EINVAL;

		/* Ensure the advertising mask is a subset of the
		 * supported mask.
		 */
		linkmode_and(state->advertising, state->advertising,
			     supported);
	}

There is no need for this additional check. Drop the functions.

Tested-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19429
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-24 00:35:00 +02:00
Markus Stockhausen
963ee6ac3f realtek: avoid interrupt storm on mass packet receive
RTL83xx devices have two types of receive interrupts for each of its
8 rings. One for packet received and another for ring overflow. When
the switch is flooded with incoming packets the receive handler will
disable the packet receive notification but still keeps the overflow
notification enabled. While the receive path "slowly" processes the
received packets each new packet triggers the overflow IRQ again. The
device becomes unresponsive and eventually produces messages like:

[18441.709764] rcu: Stack dump where RCU GP kthread last ran:
[18441.727892] Sending NMI from CPU 1 to CPUs 0:
[18441.742300] NMI backtrace for cpu 0 skipped: idling at 0x8080e994
[18415.251700] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[18415.271350] rcu:     0-...!: (0 ticks this GP) idle=d740/0/0x0 ...
[18415.303046] rcu:     (detected by 1, t=6004 jiffies, g=230925, ...
[18415.326095] Sending NMI from CPU 1 to CPUs 0:
[18415.340540] NMI backtrace for cpu 0

Fix this issue by always disabling receive and overflow interrupts at
the same time.

Test with hping3 --udp -p 5021 -d 1400 --flood 192.168.2.72

Before (3sec run):
[183260.324846] rtl838x-eth 1b00a300.ethernet eth0: RX buffer overrun: status 0x101, mask: 0x7ffeff
[183260.340524] rtl838x-eth 1b00a300.ethernet eth0: RX buffer overrun: status 0x1, mask: 0x7ffeff
[183260.345799] net_ratelimit: 489997 callbacks suppressed

After (3 sec run):
[  373.981479] rtl838x-eth 1b00a300.ethernet eth0: rx ring overrun: status 0x101, mask: 0x7fffff
[  374.031118] rtl838x-eth 1b00a300.ethernet eth0: rx ring overrun: status 0x101, mask: 0x7fffff
[  377.919996] net_ratelimit: 34 callbacks suppressed

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19365
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-18 23:52:54 +02:00
Markus Stockhausen
926ffa10b4 realtek: simplify RTL8218B/RTL8214Fx detection
The current implementation has several issues:

- it uses the hacky phy_port* macros
- it uses SoC dependent raw pages
- it disables/enables SoC dependent polling

Get rid of these dependencies and access the mdio bus the normal way.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19372
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-18 23:36:51 +02:00
Jonas Jelonek
6432b41180 realtek: rtl931x: fix setting number of leds per port
In rtl931x_led_init, the number of leds per port is not properly set. It
currently uses a hardcoded value of 1 which seems to be taken initially
from a specific device. This hardcoded value assumes any port always has
exactly two leds.

The RTL930x variant - rtl930x_led_init - does a better job at this. So
take it and use it for RTL931x too with the corresponding register.
While at it, rename the function to a proper naming scheme.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19241
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-07-13 16:47:42 +02:00
Markus Stockhausen
d2108c2c58 realtek: enhance RTL930x SerDes/PLL/CMU interoperability
The operating mode of a SerDes must be aligned with the attached PHY or
SFP module. That does not only require to change the protocol (e.g. SGMII,
10Gbase-R, ...) but also the speed (e.g. 1.25G). For this the SerDes must
be re-initialized properly.

- It must be taken into power down
- The PLL speed must be set
- Maybe the CMU (clock management unit) must be resetted
- The new mode must be set
- The state machine must be resetted
- The power must be reactivated

Until now this sequence is bugged. First the driver relies on a clean
setup from U-Boot (rtk network on) and second trying to to change mode
and PLL speeds does not work at all. And not to forget: Currently two
adjacent SerDes cannot drive SGMII/HSGMII at the same time. Fix this by
taking care about the right SerDes/PLL/CMU command init order.

P.S. This code is inspired by the work of Jan Hofmann, who tried to
enable parallel SGMII/HSGMII mode. The only missing bit was a proper CMU
reset sequence.

Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19220
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-11 10:05:52 +02:00
Markus Stockhausen
9d31db2833 realtek: add RTL931x support to rt-loader
The RTL931x devices have an other register that describes the
current RAM configuration. Enhance the identification routine.

Tested on LGS352C (RTL9311).

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19284
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-07-03 11:42:21 +02:00
Markus Stockhausen
978d24ce40 realtek: rt-loader bootbase device enhancement
Until now the rt-loader only works on U-Boot driven devices where the
environment (e.g. coprocessor) is usually setup properly. Devices like
the ZyXEL GS1920 series use BootBase as start environment and skip
some of the basic initialization steps. rt-loader will fail in these
cases. Take care about the CP0 registers.

Additionally enhance the documentation of the printf implementation.
It was optimized during the different revisions of the initial PR.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19253
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-29 17:41:20 +02:00
Markus Stockhausen
e32977f7ac realtek: Convert LGS310C to compressed kernel
There are too many supported Realtek devices so avoid activating the
rt loader recipe in the default builds. Just start with the LGS310C.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18397
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-28 16:14:55 +02:00
Markus Stockhausen
ae0a1f5b08 realtek: add rt-loader recipe
To make use of the new rt-loader provide the needed recipes.
This has been tested with the following devices:

- rtl838x Linksys LGS310: initramfs & flash
- rtl930x Zyxel XGS1210: initramfs

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18397
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-28 16:14:55 +02:00
Markus Stockhausen
ccbff8bbdd realtek: add rt-loader (runtime loader)
The bootloader of many Realtek switches only supports gzipped kernel images.
With limited flash space that might get critical in future versions. For better
compression allow support for compressed images. For this a new loader was
developed. Several ideas have been taken over from the existing lzma loader
but this has been enhanced to make integration simpler. What is new:

- Loader is position independent. No need to define load addresses
- Loader identifies device memory on its own
- Loader uses "official" upstream kernel lzma uncompress
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/decompress_unlzma.c
- Loader uses "official" UNMODIFIED nanoprintg that is used by several
  bare metal projects. https://github.com/charlesnicholson/nanoprintf

Compiled the loader ist just under 12KiB and during boot it will show:

rt-loader
Found RTL8380M (chip id 6275C) with 256MB
Relocate 2924240 bytes from 0x80100000 to 0x8fce0000
Extract kernel with 2900144 bytes from 0x8fce521c to 0x80100000...
Extracted kernel size is 9814907 bytes
Booting kernel from 0x80100000 ...

[    0.000000] Linux version 6.12.33 ...
[    0.000000] RTL838X model is 83806800
...

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18397
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-28 16:14:55 +02:00
Markus Stockhausen
6a1d7bf52b realtek: overwrite c22 polling unconditionally on RTL930x
During setup the mdio driver decides the polling mode of the 4 smi
busses depending on the DTS phy settings. This works as follows:

- set polling to c45 if at least one phy is ethernet-phy-ieee802.3-c45
- set polling to c22 if all phys are ethernet-phy-ieee802.3-c22

On RTL930x it is not possible to switch to c22 if uboot has set c45
before. Fix this by overwriting the bitfield properly. While we are
here:

- Sort variables according to kernel style (inverse christmas tree)
- Initialize fields properly with  = { 0 }
- Use GENMASK() for better readability
- Make use of RTMDIO_MAX_SMI_BUS

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19161
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-25 13:29:00 +02:00
Markus Stockhausen
83880cd01e realtek: Use Otto timer on RTL931x
Until now the timer management on the RTL931x devices depends
on the MIPS default timer. Looking at the clock progress on
these devices one can see that it is totally off. It is running
at half the required speed (e.g. if 1 minute passes the date
command shows that according to the timers only 30 seconds have
elapsed). This is a mix from wrong DTS and bad startup code.

This is not only a cosmetic issue but has effects on every
delay operation inside the kernel. Switch RTL931x to the proven
Otto timer.

Tested on LGS352C based on RTL9311.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19205
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 23:12:02 +02:00
Markus Stockhausen
ee46517a63 realtek: build Otto timer for RTL931x
The Otto timer is very helpful on the RTL931x devices.
Include it into the builds.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19205
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 23:12:02 +02:00
Markus Stockhausen
f1257b1ca3 realtek: backport MIPS GIC patch
Upstream has gained support for forced affinity settings in the MIPS
GIC interrupt controller. This is needed to enable the Otto timer on
the RTL931x platform. See

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/
commit/?id=2250db8628a0d8293ad2e0671138b848a185fba1

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19205
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 23:12:02 +02:00
Jonas Jelonek
12f13b227c realtek: remove patches, files and config for 6.6
Remove all files etc. for 6.6 because 6.12 is default now.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19139
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 16:38:11 +02:00
Jonas Jelonek
1cd68e915d realtek: switch to 6.12 as default
Use Linux 6.12 as default for all subtargets.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/19139
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 16:38:11 +02:00
Markus Stockhausen
cbf0d662c2 realtek: make use of serdes helper for Zyxel XGS1210-12
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. For
this device it is only a substitution of the existing DTS configuration.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 16:37:33 +02:00
Markus Stockhausen
eea6c5b3ea realtek: make use of serdes helper for Zyxel XGS1250-12
Use the new INTERNAL_PHY_SDS() helper to describe the SFP ports. For
this device it is only a substitution of the existing DTS configuration.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/18851
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-06-22 16:37:33 +02:00