Commit graph

859 commits

Author SHA1 Message Date
Markus Stockhausen
f21475839f realtek: fix stall after restart of otto timer
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Once tested this will go upstream.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19468
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-10 22:02:47 +02:00
Harshal Gohel
522294eeef realtek: rtl931x: Fix l2 fdb entry handling
Previous implementation was directly copied from rtl930x and was not
working. Table field offsets are different between rlt931x and rtl930x

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19580
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-10 21:59:02 +02:00
Harshal Gohel
a4b8d80050 realtek: rtl931x: Add missing rma_bpdu_fld_pmask
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
The .rma_bpdu_fld_pmask is not used anywhere in the code for RTL930x nor
RTL931x. But the RTL930x was still initializing this member. To avoid
problems in the future, simply initialize it also on RTL931x.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19569
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-10 14:35:40 +02:00
Harshal Gohel
743f2cd731 realtek: rtl931x: Don't use RTL8xx port flooding initialization
Neither the RTL930x not the RT931x use the BPDU flooding mechanism which
was used for other SoCs. At the same time, the RTL931x must use the same
debugfs initialization function as RTL930x.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19569
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-10 14:35:40 +02:00
Markus Stockhausen
07a04d8485 realtek: RTL930x: reorganize mdio functions and SerDes register layout
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
Build and Push prebuilt tools container / Build and Push all prebuilt containers (push) Waiting to run
Build Toolchains / Build Toolchains for each target (push) Waiting to run
The RTL930x mdio functions are scattered around the code. Relocate
them to the bus (still inside the ethernet driver). With this change
the phy identification looks into the proper registers. The SerDes
phy identifier (register 2/3) must be changed.

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 RTL930x 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/19692
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-10 11:47:30 +02:00
Markus Stockhausen
7cf7f7c6b9 realtek: add NAND targets for RTL93xx
Some known RTL93xx devices like the Linksys LGS328C or LGS352C are
NAND based. These require additional drivers and packages (e.g. UBI).
The current subtargets are already taylored down for devices with
only 16MB flash. Adding features that are not used will only make
the storage situation more complicated.

Add two new subtargets for RTL93xx that include the basic NAND, UBI
and MTD features. To achieve this do the following:

- Create new subtarget folders
- Copy the existing config and makefiles over
- Add the basic additional features
- Mark them as SOURCE-ONLY
- Add empty image makefiles
- Remove unneded NAND/MTD features from existing configs

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19700
Signed-off-by: Robert Marko <robimarko@gmail.com>
2025-08-10 11:46:52 +02:00
Markus Stockhausen
8eea855846 realtek: switch Zyxel GS1900 initramfs recipe to rt-loader
These devices need a tiny (<8MB) initramfs. There are first
occurrences where this fails with newer kernels and diagnostic
packages.

Switch the recipe over to use lzma compression and rt-loader.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19687
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-08 18:29:21 +02:00
Markus Stockhausen
5f06b8ebbc realtek: dsa: rename tagged_ports to member_ports
The current variables tagged_ports and untagged_ports suggest that
these are distinct and describe only the ports in each of these
configuration types.

That is wrong. The hardware is configured via member ports and
untagged ports. The first one being a superset of the second.
Rename the variables to reflect that.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19684
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-08 18:04:57 +02:00
Harshal Gohel
f6603de71d realtek: rtl93xx: Add learning and flooding enable/disable
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Both RTL930x and RTL931x were missing the code to support enabling and
disabling MAC address learning and unknown unicast flooding on a per-port
basis.

* rtl93*x_enable_learning() allows toggling of dynamic MAC learning on
  individual ports by modifying the L2 learning constraint control
  register.
* rtl93*x_enable_flood() provides the ability to control unknown unicast
  flooding behavior, disabling forwarding when set. If it is enabled, it
  will just forward it. If it is disabled, packets will simply be dropped.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19581
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-08 13:56:58 +02:00
Harshal Gohel
4c4cecab2f realtek: rtl93xx: Add GPIO access register definitions
mach-rtl83xx.h contained the required register definitions for older SoC
families but was missing it for RTL930x and RTL931x.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 18:40:30 +02:00
Sven Eckelmann
92489f50c7 realtek: rtl931x: Fix size of TRK_MBR_CTRL group block
Each MBR ctrl block has 64 bits to store the 56 possible ports. The offsets
between the groups is therefore also 64 bit.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 18:40:30 +02:00
Harshal Gohel
62938204db realtek: rtl931x: Add smi_poll_ctrl
The comment incorrectly stated that RTL931X doesn't have smi_poll_ctrl. But
there is actually a register for using it.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 18:40:30 +02:00
Harshal Gohel
56499702a3 realtek: rtl931x: Sync family parameters with RTL930x
Some of the parameters added to RTL9300_FAMILY_ID are missing for
RTL9310_FAMILY_ID. Simply add the missing ones to keep sharing code between
the two SoCs.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19574
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 18:40:30 +02:00
Harshal Gohel
e45d783bce realtek: rtl931x: Fix VLAN tagging and untagging
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
* In RTL931x, bit 31 of the (4th column) of 802_1Q_VLAN_QINQ table
  indicates the validity of l2 tunnel. Before bit 63 (3rd column)
  was being checked for validity of l2 tunnel.

* The untagged_ports requires 64 bits to represent 56 ports. Do not
  store u64 in u32 variable

* First 24 ports are represented in the 2nd register not just first 20

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19576
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 18:33:09 +02:00
Issam Hamdi
feec7cf34d realtek: dsa: rtl83xx: flush scheduled work on removal
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
The workqueue items don't need to be processed directly when they are
scheduled. It can happen that they are simply processed at a much later
time. It is therefore necessary to ensure that all workqueue items of a
driver are no longer being processed before the driver (or structures of
this driver) are destroyed.

When skipping this step, the driver driver can cause a kernel Oops on
reboot.

Unfortunately, it is not recommended [1] to flush items out of the system
workqueue - simply because this can cause deadlocks. The driver itself must
have a private workqueue which is then flushed.

[1] https://lkml.kernel.org/r/49925af7-78a8-a3dd-bce6-cfc02e1a9236@I-love.SAKURA.ne.jp

Signed-off-by: Issam Hamdi <ih@simonwunderlich.de>
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19570
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 17:29:14 +02:00
Harshal Gohel
6473e3ed5e realtek: rtl931x: Fix link status get not fetching correct status
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
Just like rtl930x, rtl931x also requires two reads to fetch current link
status.

While at it, rename the function to a proper naming scheme.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Co-developed-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19578
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 16:01:51 +02:00
Harshal Gohel
445af8c038 realtek: rtl930x: Fetch link status for all ports in switch IRQ
Link status needs to be read twice, and a single register value is
enough for determining link status for all the ports

It is not necessary to go through each potential port separately and later
actually identify for which ports the interrupt actually was. The helper
for_each_set_bit() directly iterate through all set bits.

While at it, rename the function to a proper naming scheme.

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Co-developed-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19578
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 16:01:51 +02:00
Harshal Gohel
9ccfca3303 realtek: dsa: enhance pcs_get_state() for RTL93xx
Currently the SerDes driven SFP ports give strange ethtool readings
on RTL93xx 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.

Suggested-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19575
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 15:50:01 +02:00
Harshal Gohel
2645c4afbb realtek: rtl93xx: Do not use media register to get link status
The media_sts register only shows type of link, fiber/copper,
and has nothing to do with the link status

Signed-off-by: Harshal Gohel <hg@simonwunderlich.de>
Signed-off-by: Sharadanand Karanjkar <sk@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/19575
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 15:50:01 +02:00
Markus Stockhausen
17822d5d18 realtek: use consistent definition in DTS for SFP(+) ports
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
We are slowly getting to the point where the mdio driver will be
carved out from the ethernet driver. Since the beginning it had
the feature to hand out SFP serdes as phys. So one can access
them from the phy driver. This will be kept during the final
migration and it even will provide a consistent interface for the
phy/serdes registers.

With this being done we need to identify how to handle the affected
ports in a generic way for all targets. Doing first things first,
this starts with a consistent DTS. Currently we have:

for RTL838x + Zyxel XGS1210:
  phy-mode = "1000base-x"
  managed = "in-band-status"
  phy-handle = ...

for all other RTL93x devices:
  phy-mode = "10gbase-r"
  managed = "in-band-status"
  pseudo-phy-handle = ...

Looking at the phylink kernel code one can see a nifty detail.
There is dynamic phy bringup depending on the mode.

int phylink_fwnode_phy_connect(struct phylink *pl,
                               const struct fwnode_handle *fwnode,
                               u32 flags)
{
        struct fwnode_handle *phy_fwnode;
        struct phy_device *phy_dev;
        int ret;

        /* Fixed links and 802.3z are handled without needing a PHY */
        if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
            (pl->cfg_link_an_mode == MLO_AN_INBAND &&
             phy_interface_mode_is_8023z(pl->link_interface)))
                return 0;
        ...
}

Where 802.3z means 1000base-x or 2500base-x. Aligning this with
IEEE specs it means essentially:

- 10gbase-r defined ports with phy-handle must statically bring up
  a phylink from the beginning that immediately depends on a
  phy read_status() implementation.

- 1000base-x/2500base-x defined ports will dynamically bringup a
  phylink during link detection regardless of a phy-handle. So
  it usually runs at the moment when a SFP has been plugged in.

We currently still rely on a phy-handle but do not want to bring
up the phy immediately. Commit 4457c1eee4 ("realtek: rtl93xx:
support SFPs with phys") tried to fix exactly that error for
10gbase-r definied ports. Kernel shows "sfp sfp-p8: sfp_add_phy
failed: -EBUSY" in that case.

But it did it in the wrong way. It implemented a workaround by
introducing a DTS property "pseudo-phy-handle". Instead it
should have simply converted the DTS nodes to 1000base-x.

Revert the commit and fix the DTS with wrong definitions. From
now on we have a consistent SFP definition throughout all DTS
and targets.

Aside from the positive effect this setting has it is more or
less an arbitrary speed definition. When plugging in the SFP the
real speed will be choosen dynamically.

Fixes: 4457c1eee4 ("realtek: rtl93xx: support SFPs with phys")
Tested-By: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/19648
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2025-08-07 13:47:27 +02:00
Markus Stockhausen
2c501d9db9 realtek: rtl930x: convert Hasivo S1100W to lzma only.
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks failed
Build Kernel / Build all affected Kernels (push) Has been cancelled
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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
Some checks are pending
Build Kernel / Build all affected Kernels (push) Waiting to run
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