wireguard-tools: use kconfig dependency for ip instead of runtime
The conditional runtime dependency on the ip package was originally
intended to only pull in the ip package when busybox ip is not
configured. However, in APK-based builds the BUSYBOX_CONFIG_*
variables may not be resolvable at package metadata generation
time, causing the ip dependency to be unconditionally baked into
the .apk package. This forces users to install ip-tiny or ip-full
even though busybox already provides the ip command.
Revert to the previous +@BUSYBOX_CONFIG_IP / +@BUSYBOX_CONFIG_FEATURE_IP_LINK
kconfig-level dependencies. These ensure busybox ip support is
enabled at config time without creating a runtime package dependency.
Both options default to y, and wireguard.uc only uses basic
ip link commands that busybox fully supports.
Like the PHY_C22() macro before add a helper that allows to define
a C45 based phy. It works basically the same with two parameters
PHY_C45(port_number, bus_address) where
- port_number is the absolute overall unique phy number
- bus_address is the location of the phy on the bus
As a first consumer adapt the Xikestor SKS8300-8T devicetree.
Shiji Yang [Tue, 31 Mar 2026 00:10:30 +0000 (08:10 +0800)]
kernel: tune 24kc instead of 34kc for mips32r2
GCC generates the same code for 24kc and 34kc. Since we have
converted all 34kc targets to the 24kc, it's better to switch
kernel -mtune to 24kc to avoid confusing developers.
airoha: backport minor fixup for Ethernet driver on Offload Scenario
Backport minor fixup merged upstream for Ethernet driver on Offload
Scenario. This is to continue the effort of keeping the Airoha Ethernet
driver synced with the upstream version.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Backport 2 patches from [1] that cleanup the i2c-rtl9300 upstream driver.
They have been long accepted and are already in mainline kernel as of 7.0-rc1.
The "100-rtl9300-i2c-add-more-speeds.patch" required refreshing after adding
these backport patches.
realtek: dsa: move fib_entries to config structure
The fib_entries attribute is a device specific constant.
Therefore move it into the configuration structure. Add
a comment why someone used 16K fib_entries for RTL931x
instead of the possible 32K.
Robert Marko [Tue, 31 Mar 2026 16:54:47 +0000 (18:54 +0200)]
generic: 6.18: hack: io_uring: zcrx: Use IS_REACHABLE() instead of IS_ENABLED()
We patch DMA_BUF to make it tristate, so once ALL_KMODS is selected it will
be built as a module even if previously disabled in the config.
So, since IO_URING_ZCRX does not depend on DMA_BUF linking will fail with:
aarch64-openwrt-linux-musl-ld: Unexpected GOT/PLT entries detected!
aarch64-openwrt-linux-musl-ld: Unexpected run-time procedure linkages detected!
aarch64-openwrt-linux-musl-ld: io_uring/zcrx.o: in function `io_release_dmabuf':
io_uring/zcrx.c:94:(.text+0x20): undefined reference to `dma_buf_unmap_attachment_unlocked'
aarch64-openwrt-linux-musl-ld: io_uring/zcrx.c:97:(.text+0x30): undefined reference to `dma_buf_detach'
aarch64-openwrt-linux-musl-ld: io_uring/zcrx.c:99:(.text+0x3c): undefined reference to `dma_buf_put'
aarch64-openwrt-linux-musl-ld: io_uring/zcrx.o: in function `io_import_dmabuf':
io_uring/zcrx.c:125:(.text+0x1b20): undefined reference to `dma_buf_get'
aarch64-openwrt-linux-musl-ld: io_uring/zcrx.c:132:(.text+0x1b34): undefined reference to `dma_buf_attach'
aarch64-openwrt-linux-musl-ld: io_uring/zcrx.c:139:(.text+0x1b48): undefined reference to `dma_buf_map_attachment_unlocked'
make[6]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
So, lets use IS_REACHABLE() to check for CONFIG_DMA_SHARED_BUFFER instead
to avoid adding a dependency to CONFIG_DMA_SHARED_BUFFER.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Use the compiled asus_rt-ax52-pro-initramfs.trx file from the this repo.
Connect the PC via LAN to one of the yellow router ports and wait until your PC to get a DHCP lease.
Browse to http://192.168.50.1 or http://www.asusrouter.com/
If your router is brand new, finish the setup process and log into the Web-UI.
Navigate to Administration → Firmware Upgrade or use this link http://www.asusrouter.com/Advanced_FirmwareUpgrade_Content.asp.
Upload the .trx file to router
Wait for it to reboot
trx image is initramfs version. You must upgrade to squashfs version.
Browse to http://192.168.1.1/cgi-bin/luci/admin/system/flash
Upload asus_rt-ax52-pro-squashfs-sysupgrade.bin and use sysupgrade -n
Wait for it to reboot
SSH to 192.168.1.1 and set a root password, or browse to http://192.168.1.1
-------Revert to stock asus firmware ---------:
1: Download the rt-ax52 firmware from ASUS official website. Save the firmware to tftp server directory and rename to RT-AX52.trx
2: Connect the PC with TFTP server to the RT-AX52. Set a static ip on the ethernet interface of your PC. (ip address: 192.168.1.70, subnet mask:255.255.255.0)
3: Conect to the serial console, power on again, interrupt the autoboot process by pressing '4' when prompted. $ ubi remove linux
$ ubi remove jffs2
$ ubi remove rootfs
$ ubi remove rootfs_data
$ ubi create linux 0x45fe000
$ reset
then the dut will reboot,interrupt the autoboot process by pressing '2' when prompted. 2: Load System code then write to Flash via TFTP.
Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N) $: enter y
you will see the follow, type enter directly:
Input device IP (192.168.1.1) ==:
Input server IP (192.168.1.70) ==:
Input Linux Kernel filename (RT-AX52.trx) ==:
The Realtek target currently uses two phy macros to simplify the
device dts.
- EXTERNAL_PHY() to denote a phy attached to the SoC
- INTERNAL_PHY() to denote an internal PHY (inside the SoC)
There is no benefit doing this. The topology around a port/phy is
well defined by the port macros. They link port, phy, pcs and even
leds. The only consumer of the attribute "phy-is-integrated" is
inside the dsa driver and that is being refactored.
As a first step define a new more meaningful PHY_C22() macro that
describes a c22 capable phy. This does not need to care about the
external/internal relation. To make it even more useful for the
RTL93xx targets with multiple mdio busses give it two parameters
PHY_C22(port_number, bus_address) where
- port_number is the absolute overall unique phy number
- bus_address is the location of the phy on the bus
For RTL83xx these two parameters will usually be the same. Instead
of three steps (inventing the macro, converting the consumers and
removeing the old macor) do a one-step conversion for the existing
EXTERNAL_PHY() macro.
The dsa driver currently has different attributes to denote what
hardware is around a port:
- phy_is_integrated: true if phy is not driven by a serdes
- phy: the type of the attached phy (e.g. 0=NONE, 2=RTL8218B, ....)
- pcs: link to a serdes pcs instance
This is somehow redundant and especially the phy type should be only
part of the phy driver and is not needed by the dsa driver at all.
Remove the redundancy by simply keeping a boolean attribute "phy" that
flags a phy driven port and can be used similar to the pcs (pointer)
attribute. With that the driver can check phy/pcs as follows:
- if (ports[i].pcs) -> port has a dedicated serdes
- if (ports[i].phy) -> port has a dedicated phy
That implemented, the "phy-is-integrated" attribute of a phy can be
removed from the dts. This will be a separate commit. As a side effect
the following (annoying) boot message for kernel 6.18 gets fixed.
OF: /switchcore@1b000000/mdio-controller/mdio-bus@0/ethernet-phy@24:
Read of boolean property 'sfp' with a value.
Jonas Jelonek [Mon, 30 Mar 2026 09:46:29 +0000 (09:46 +0000)]
realtek: force in-band autoneg on XGS1250-12 A1 10G PHYs
In kernel 6.18, upstream added a change to the Aquantia PHY driver which
reports autoneg and inband capabilities as the PHY supports it, and
configures it accordingly in the PHY [1]. Due to how phylink works, it
then decides to turn off in-band signalling and prefer outband signalling
via MDIO.
We do not fully support running a USXGMII link with disabled
autonegotiation which leads to a non-working link between RTL93xx switch
and Aquantia PHYs running on USXGMII. To workaround this issue until
this support is added (if it is properly supported by the hardware),
force the Aquantia PHYs on affected devices to use inband signalling
instead of outband signalling. To achieve this, one can add
Jonas Jelonek [Mon, 30 Mar 2026 09:42:08 +0000 (09:42 +0000)]
realtek: dts: use SWITCH_PORT_LED for XGS1250-12
Switch the common DTS for Zyxel XGS1250-12 variants to the recently
added SWITCH_PORT_LED macro to reduce boilerplate and make the DTS
cleaner. As a side effect, this also assign labels to the port nodes so
they can be referenced by the variant-specific device tree sources.
Daniel Golle [Tue, 31 Mar 2026 02:13:41 +0000 (03:13 +0100)]
kernel: update MxL862xx DSA driver
Introduce fix which prevents the kernel from crashing in case the mxl862xx
driver fails to probe due to outdated firmware running on the switch.
Cancel all pending work and prevent rescheduling of counter polling in case
the driver errors out during probe.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Sander Vanheule [Thu, 19 Feb 2026 15:13:06 +0000 (16:13 +0100)]
realtek: rtl839x: support GS1900-48 A1 port LEDs
Add the RTL8231 controlling the port LEDs to the devicetree, so users
can enable them. Using the appropriate link name, the netdev trigger can
be used to reflect the port status. As no hardware port status
offloading is supported, blinking on traffic could result in increased
load due to the numerous LED updates.
Sander Vanheule [Thu, 19 Feb 2026 15:12:47 +0000 (16:12 +0100)]
realtek: rtl839x: enable RTL8231 LED driver
To enable the use of the RTL8231 to control (port) LEDs, the driver
needs to be enabled in the build. Incorporate it into the kernel, so any
LED consumers also work in failsafe mode.
Sander Vanheule [Thu, 19 Feb 2026 15:11:41 +0000 (16:11 +0100)]
realtek: rtl839x: add port LED peripheral disable
Add a pinctrl-single node to the switch GPIO/LED control register that
disables the port LED peripheral when selected. When an RTL8231 is
instantiated, this is required to prevent the user config from being
overwritten by the peripheral.
As this is technically not a pin mux operation, but rather a peripheral
disable, using pinctrl-single for this purpose is bit of a hack, but it
does the job.
Sander Vanheule [Thu, 19 Feb 2026 20:17:07 +0000 (21:17 +0100)]
realtek: disable synchronous operation on RTL8231
It may be possible that the bootloader has left an RTL8231 expander
configured for synchronous operation, which requires the user to signal
that the new GPIO/LED states should be latched.
As drivers typically perform one operation at a time for the higher
level kernel framework, this would require a latch on every update,
which is not very useful. Disable synchronous operation to keeps things
simple.
Sander Vanheule [Thu, 19 Feb 2026 20:17:58 +0000 (21:17 +0100)]
realtek: fix RTL8231 LED toggle interval clamping
The loop scanning the available toggle rates would stop when the
requested interval exceeded the tested interval. Since the intervals are
searched from small to large, this would always trigger on the shortest
interval, or skip to the largest interval for small requested values.
To correctly clamp (ceil) the toggle rate, the loop needs to continue
until the condition is met, instead of breaking the loop.
Fixes: 6ef6014887c3 ("realtek: Add pinctrl support for RTL8231") Signed-off-by: Sander Vanheule <sander@svanheule.net>
Sander Vanheule [Thu, 19 Feb 2026 20:27:16 +0000 (21:27 +0100)]
realtek: mark gpio-regmap patch as upstreamed
The code in 800-gpio-regmap-Bypass-cache-for-shadowed-outputs.patch
was accepted upstream as commit 897396b418d1 ("gpio: regmap: Bypass
cache for aliased inputs"). Update the filename to reflect the first
release containing this change.
* 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.