* RTL9301 SoC, 1 MIPS 34KEc core @ 800MHz
* 512MB DRAM
* 64MB NAND Flash
* 24 x 10/100/1000BASE-T ports
* 4 x 10G SFP+ ports
* Power LED, Console LED, Fan Fault LED
* Reset button on front panel
* LM75 temperature sensor
* Atmel AT24C02 2kb eeprom
* fan (controllable via gpio for on/off and LM75 for low/high speed)
* UART (115200 8N1) via RJ45
Installation using serial interface
-----------------------------------
1. Prepare TFTP server & connect to serial port.
2. Connect DGS-1250 to your computer or network with one of the
1G ports. All of them will be fine.
3. Power on DGS-1250 and interrupt autoboot with "&".
4. Change U-Boot startup sequence
> setenv silent
> setenv bootcmd 'cp.l 0xb4200000 0x84000000 0x300000; bootm 0x84000000'
> saveenv
5. Enable networking within U-Boot.
> rtk network on
6. Set switch IP and TFTP server IP (optional, adjust to your setup).
> setenv ipaddr <ip>
> setenv serverip <ip>
7. Download initramfs image from TFTP server.
> tftpboot 0x84000000 <image name>
8. Boot with the downloaded image.
> bootm 0x84000000
9. With rambooted OpenWrt, backup the stock firmware.
THIS IS CRITICAL! /dev/mtd3 contains data that is not provided
in the downloadable vendor firmware images.
10. Copy sysupgrade image to the device.
11. Perform sysupgrade with the sysupgrade image.
12. After reboot, you should have functional OpenWrt.
Installation using OEM webinterface
-----------------------------------
This is not possible because the vendor image uses a ubifs based
loading technique with encrypted images. To be precise the boot
sequence basically runs as follows.
1. U-Boot starts
2. U-Boot mounts 62MB ubifs from mtd3
3. U-Boot reads Linux kernel from file uImage inside ubifs
4. Linux starts (this is a initramfs image)
5. Linux mounts ubifs
6. Linux calls a loader binary
7. Depending on current configuration first (file Image1) or
second firmware image (file Image2) is loaded and decrypted
8. Inside the decrpyted firmware image there is a executable
named “switch”
9. "switch" executable is run and the switch comes alive
Reverting to stock firmware
---------------------------
1. Boot OpenWrt from initramfs (like in installation section above)
2. Restore partition /dev/mtd3 from backup
3. Erase Openwrt special U-Boot env
# mtd erase mtd1
4. reboot
The four TGRX pages are currently mapped into the page range 4-7 for even
10G serdes. This is only partly right. TGRX0/1 better aligns with RTL93xx
pages TGX_STD_0/TGX_STD_1. Change the mapping. No code update needed as
the pages are not yet used anywhere.
The ANA_RG pages of the RTL839x SerDes are a wild mix of WDIG, ANA_MISC
and ANA_1G2 data. Its current mapping to the TGX_STD_0 register does
not match at all. From the coding it makes most sense to remap it to the
ANA_1G2/ANA_1G2_EXT range. Adapt all consumers in the pcs driver
accordingly.
With all the recent development about RTL93xx serdes it has become
clear that the RTL839x ANA_TG page mapping is not perfect. Until
know it is mapped to pages 10/11. As its naming suggests these are
serdes analogous register settings for 10G. Map it to the appropriate
ANA_10G pages to align better with RTL93xx. Adapt all consumers
in the pcs driver accordingly.
The initial page naming of the debugfs page registers in the mdio
serdes driver was a mix of RTL839x and RTL93xx. Developing the
Realtek pcs driver, it was discovered that the RTL93xx IP block
shares a lot of the registers with the RTL8295 PHY.
The RTL839x serdes development is quite okay and currently on hold.
Thus drop the RTL839x derived page names and substitute them for
their RTL93xx counterpart.
This is only a cosmetic change for better readability.
Realtek switches have a very simple network adapter for the SOC.
They can ship packets via DMA without further offloading features.
Even on the RTL931x devices they can barely reach 50MB/s. In the
dts there is a mix of 1G/10G definitions. To be consistent and
better reflect the performance set the link speed to 1000.
This is only cosmetic.
airoha: an7581: drop airoha,x2-mode related property and enable in device
Drop airoha,x2-mode related property from the DTSI and enable them only in
the relevant devices that use a PCIe0 line. x2-mode should be enabled only
for the WiFi card that would use it as it might cause problem for WiFi card
that expect 2 single PCIe x1 line instead of a single PCIe x2 line.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Zoltan HERPAI [Sun, 8 Feb 2026 17:11:33 +0000 (17:11 +0000)]
kernel/mxs: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Rany Hany [Sun, 29 Mar 2026 15:17:48 +0000 (15:17 +0000)]
ramips: mt7621: disable CONFIG_LIST_HARDENED
It appears that CONFIG_LIST_HARDENED causes the system to
hang when restarted. I was unable to determine the cause
of the crash so disabling CONFIG_LIST_HARDENED seems like
an acceptable workaround for the time being.
The issue only occurs on reboot.
Fixes: https://github.com/openwrt/openwrt/issues/20099 Signed-off-by: Rany Hany <rany_hany@riseup.net> Link: https://github.com/openwrt/openwrt/pull/22672 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Sat, 27 Dec 2025 23:10:51 +0000 (23:10 +0000)]
realtek: add patch to extend upstream sfp smbus support
Add patches that extends the upstream smbus support in sfp driver. This
only supports SMBus byte operations and in that case, disables hwmon and
prints warnings because of that. Using the word/block capability of our
I2C controller is totally fine for all that functionality.
Jonas Jelonek [Sun, 30 Nov 2025 12:34:33 +0000 (12:34 +0000)]
realtek: dsa: 6.18: adjust mac ops and callbacks
Between 6.12 and 6.18, several DSA switch ops have changed.
phylink_mac_* ops were moved out of dsa_switch_ops into dsa_switch using
phylink_mac_ops. Add new definitions for that and adjust the callbacks
accordingly to work with the different signatures.
get_mac_eee() has been dropped and support_eee() was added.
remove_new() has been dropped completely, allowing us to use remove()
again.
Jonas Jelonek [Sun, 30 Nov 2025 10:40:39 +0000 (10:40 +0000)]
realtek: phy: 6.18: drop shared priv access helper
Between v6.12 and v6.18, struct phy_package_shared was moved from
include/linux/phylib.h to drivers/net/phy/phy_package.c and thus made
internal/unavailable for other drivers.
Our PHY driver used a helper to access the shared priv. With v6.18, it
doesn't work anymore (due to missing access to internal fields of struct
phy_package_shared) but upstream has an equivalent helper for that. Drop
ours and use the upstream helper.
Jonas Jelonek [Wed, 21 Jan 2026 23:26:28 +0000 (23:26 +0000)]
realtek: 6.18: adapt SFP SMBus patches
Adapt our downstream patches for SMBus SFP functionality to kernel 6.18.
Upstream gained support for SMBus byte access on SFP and a patch to
extend that to word and block access is pending.
These downstream patches aren't acceptable for upstream and will need to
be adapted. However, keep them for now to maintain functionality.
Jonas Jelonek [Sat, 28 Mar 2026 19:41:46 +0000 (19:41 +0000)]
kernel/realtek: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Robert Marko [Sat, 28 Mar 2026 11:27:35 +0000 (12:27 +0100)]
kernel/microchipsw: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Per-CPU data structures consume ~100-200KB each.
On a 4-core system configured to NR_CPUS=4, this frees approx 76 MB
of RAM: (512 - 4) × 150 KB = ~76 MB
Note: CONFIG_NR_CPUS_RANGE_{BEGIN,END}= and CONFIG_NR_CPUS_DEFAULT= are
set by the build system and will default to 2/512/64 per arch/x86/Kconfig
These are harmless metadata and don't affect memory allocation.
John Audia [Mon, 5 Jan 2026 20:02:37 +0000 (15:02 -0500)]
x86/64: 6.18: enable recent MITIGATION options
These mitigations are low-overhead, upstream-supported hardening options
that only activate on CPUs affected by their respective vulnerabilities.
Enabling them provides consistent, defense-in-depth coverage across Intel
and AMD systems without impacting unaffected hardware.
Detailed list:
- CONFIG_MITIGATION_SRSO to guard against known a vulnerability found on
AMD processors (Zen generations 1-4) for sure, maybe others. This is
tracked under CVE-2023-20569.
- CONFIG_MITIGATION_ITS to guard against a bug in BPU on some Intel CPUs
that may allow Spectre V2 style attacks. We never enabled this option
(and its dependencies).
- CONFIG_MITIGATION_SRBDS to guard against Special Register Buffer Data
Sampling on affected Intel CPUs (CVE-2020-0543), preventing cross-core
leakage of RDRAND/RDSEED/EGETKEY values.
- CONFIG_MITIGATION_SLS to guard against Spectre-v4 gadgets on x86 by
inserting speculation barriers around RET/JMP/CALL sites when required
by CPU/microcode state.
- CONFIG_MITIGATION_CALL_DEPTH_TRACKING to guard against speculative
call-stack underflow on x86 by enabling hardware-assisted depth
tracking where supported, reducing exposure to RET-based misprediction
attacks.
- CONFIG_MITIGATION_UNRET_ENTRY to guard against RET-based speculation
attacks on x86 by replacing vulnerable function returns in kernel
entry paths with UNRET sequences when required by CPU/microcode state.
John Audia [Fri, 2 Jan 2026 16:55:24 +0000 (11:55 -0500)]
rtl8812au-ct: restrict to kernels ≤ 6.18
The rtl8812au-ct driver is obsolete and replaced by rtw88. It will need
tons of work to compile against 6.18 so for now limit it to 6.12.
Co-authored-by: Mieczyslaw Nalewaj <namiltd@yahoo.com> Signed-off-by: John Audia <therealgraysky@proton.me> Link: https://github.com/openwrt/openwrt/pull/21078 Signed-off-by: Robert Marko <robimarko@gmail.com>
John Audia [Sun, 21 Dec 2025 14:00:35 +0000 (09:00 -0500)]
kernel: sound: 6.18: update module files
This kernel reorganized HDA drivers into sound/hda/ subdirectories and
split codec drivers into modular components. Core modules moved to
sound/hda/{core,common,codecs,controllers}/ with version conditionals
(@ge6.18/@lt6.18) added for backward compatibility.
John Audia [Sat, 28 Mar 2026 09:38:05 +0000 (05:38 -0400)]
kernel/x86: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Replace the two-step hrtimer initialization pattern with a single
consolidated call to hrtimer_setup().
The legacy approach of calling hrtimer_init() followed by manual
assignment to timer.function is deprecated. The new hrtimer_setup()
helper atomically initializes the timer and assigns the callback
function in one operation, eliminating the race-prone intermediate
state where the timer is initialized but lacks a handler.
mac80211: ath9k: gpio: adapt to 6.16+ gpio_chip API change
Linux 6.16 changed the return type of gpio_chip.set() from void to int.
Add a version check so the driver builds correctly on both older and
newer kernels[1].
Reintroduce old-style debugfs file_operations for kernels < 6.14 and
switch the drivers to use debugfs_short_fops + debugfs_create_file_aux
on >= 6.14. This restores compatibility with older kernels while keeping
the new debugfs API working on 6.14+.
Kernel since version 6.16 defines `SOCKWQ_ASYNC_NOSPACE` and
SOCKWQ_ASYNC_WAITDATA` in the socket_flags enum, which causes redefinition
errors when compiling the backport package[1].
Since kernel 6.12 also has them defined, the test and definition of these
constants have been completely abandoned. Thanks to this, there are
no compilation errors on either kernel 6.12 or 6.18.
platform/mikrotik: adjust hc_wlan read-callback for 6.18
Include <linux/version.h> and use preprocessor checks to select the appropriate
prototype and definition for hc_wlan_data_bin_read. The third parameter of bin_attribute
read callbacks was changed to 'const struct bin_attribute *' in Linux 6.18; this
change prevents compilation errors on newer kernels while preserving compatibility
with older ones
kbuild: extract modules.builtin.modinfo from vmlinux.o
Partially reverse https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.18.y&id=39cfd5b12160be4f57df1c3ba60139741c827616
to prevent generation of empty modules.builtin.modinfo and modules.builtin
files that cause modules compilation errors.
If an out-of-tree package or any kernel-install rule ran modprobe xyz while
the build was still in progress, and xyz had been configured =y, a clean tree
would already have xyz listed in modules.builtin; with the empty file produced
by the buggy rule it was missing, so modprobe emitted "module xyz not found"
even though the code was sitting inside the freshly built vmlinux.
serial: 8250: 6.18: add UPIO_AU case to set_io_from_upio()
This patch fixes the "Unsupported UART type 4" error by adding support
for the UPIO_AU I/O type in set_io_from_upio() (used by Au1x00 and
RT288x). It assigns the correct serial input/output functions
(io_serial_in, io_serial_out) for proper operation when UPIO_AU is
configured.
Backport minor fixes for the eip93 driver from upstream.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://github.com/openwrt/openwrt/pull/21078 Signed-off-by: Robert Marko <robimarko@gmail.com>
This patch set introduces support for using the in-tree (mainline)
EIP93 crypto driver for kernel 6.18 and later, along with additional
improvements and fixes:
- Conditional Kconfig/Makefile handling for crypto-hw-eip93 to enable use of the mainline driver with kernel 6.18+.
- Patch 926: Use software AES fallback for small requests in the EIP93 driver.
- Patch 927: Add `mediatek,mtk-eip93` compatible string for upstream kernel device trees.
- change phy_driver_register and phy_driver_unregister function calls
to phy_drivers_register and phy_drivers_unregister for compatibility
with kernel 6.18
- replace PHY_ANY_ID with "MATCH ANY PHY"
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Kevin Staley [Mon, 29 Dec 2025 13:53:20 +0000 (07:53 -0600)]
kernel: qca8k: fix host FDB on multi-CPU
On qca8k multi-CPU-port setups (e.g. qca8337 with ports 0+6 as CPU),
bridging switch user ports that use different conduits can make the host
reachable only from the ports tied to the last-programmed CPU port.
Add a pending kernel patch which makes qca8k merge CPU/DSA-port FDB
programming, so host FDB entries end up on all relevant CPU ports.
Fixes: openwrt/openwrt#17891 Signed-off-by: Kevin Staley <glaciertablet@gmail.com> Link: https://github.com/openwrt/openwrt/pull/21317 Signed-off-by: Robert Marko <robimarko@gmail.com>
realtek: mdio: provide individual bus probing function
rtmdio_probe() is a do-it-all setup function. It creates one
control structure and one bus. In the future multiple busses
will be created. As a preparation carve out the bus specific
part into an individual probing function.
Until now the central control structure is allocated via a call to
devm_mdiobus_alloc_size(). This will not be possible any longer when
multiple busses will be implemented in a future commit.
Relax that as follows:
- Define a new private "channel" structure for a mdio bus
- Allocate the central control structure with a dedicated alloc()
- Allocate only the channel structure during bus setup
- Link the channel to the central structure via chan->ctrl
Reorganize the probing function so that it becomes clearer that
the control structure is setup first and afterwards the bus is
registered.
Add a new helper macro rtmdio_ctrl_from_bus that encapuslates
the current ctrl=bus->priv lookup. This is a preparation for
the future multi-channel driver architecture. With an upcoming
commit the structures will be changed as follows:
- ctrl: contains the generic data structurs
- chan: contains the channel specific structure
This will involve changing the pointers between them
old lookup chain: ctrl = bus->ctrl
new lookup chain: ctrl = bus->chan->ctrl
The helper macro allows to easily switch the lookup in one
central location. While we are here fix a whitespace issue.
realtek: mdio: setup topology from control structure
The topology setup is bus independent and can be derived completely
from the control structure. Adapt the call parameters accordingly.
The call location is quite confusing at the moment. Being no longer
dependent from the bus call it where it makes most sense. This is
directly after the mapping setup in rtmdio_map_ports(). Doing other
bus dependent setup between these two functions is not needed
any longer.
The port specific attributes of the central control structure
have been moved over to a separate port structure. Do the same
for the (up to 4) busses. Establish a separate bus structure
that will hold data about each bus and use it in the control
structure. As a first usage type move the is_c45 attribute over.
realtek: mdio: move phy_node attribute into port structure
The phy_node attribute is defined per port. Move it into the new
port structure. Now it is clear that it belongs to the port.
While we are here rename it to dn (aka device_node) to align with
upstream style. As all usage locations must be adapted it makes
no sense to make two commits (relocate/rename) to change the
code twice.
realtek: mdio: move smi_addr attribute into port structure
The smi_addr attribute is defined per port. Move it into the new
port structure. As the devices have a maximum of 56 addresses
save some space and convert it to type u8.
While we are here harden the mapping routine that reads these
addresses from the DTS. For this check the value that is read into
smi_addr. This is usually the MDIO standard 0..31. Sadly RTL839x
devices are an exception from that and allow addresses 0..51.
To avoid device specific if/then/else cases for now implement
a "light" consistency check.
projects / thirdparty / openwrt.git / log
