Jonas Jelonek [Sun, 10 May 2026 18:44:30 +0000 (18:44 +0000)]
realtek: pcs: rtl930x: drop superfluous debug prints
The RTL930x calibration code is especially chatty. There are debug
prints for every start and end of a section corresponding to the
sections the SDK uses. In the end, this doesn't help a user much and
just wastes CPU cycles. Moreover it doesn't help in understand what is
done there. As a first step, drop "start" and "end" prints but preserve
their meaning as comments.
While at it, slightly adjust two other prints and drop one confusing
print.
Jonas Jelonek [Sat, 9 May 2026 21:25:51 +0000 (21:25 +0000)]
realtek: pcs: rtl930x: reduce chattiness and reg ops
There is no need to be extra chatty for simple writes which set a single
bit. As a nice side effect, without the prints there's no need to have
open-coded register access when there a helper that covers that.
Jonas Jelonek [Sat, 9 May 2026 20:31:46 +0000 (20:31 +0000)]
realtek: pcs: rtl931x: reduce chattiness
The SerDes setup code for RTL931x still has a lot of debug prints as
pr_info from former times. A lot has changed and we don't need that
rather useless chattiness anymore. We reached a state where we have a
standalone setup of most hardware modes. The registers printed are still
"documented" in rtpcs_931x_sds_config_hw_mode and
rtpcs_93xx_sds_config_cmu. For every other issues we rely on comparison
of full SerDes dumps instead of cherry-picked registers.
Flashing OpenWrt will overwrite BootExtension + ZyNOS. BootExtension
functionality is not available anymore then. The U-boot/Bootbase still
has some limited functionality which can be used in emergency cases.
Installation
============
Simple web upgrade:
1. Take the OpenWrt factory.bin image generated by the build.
2. In the ZyNOS web UI, login and go to Maintenance -> Firmware Upgrade.
3. Under "Boot Image", make sure the Config Boot Image is set to 1. In
other words, make sure the switch booted from firmware image 1 or it
will do so on next reboot.
This is crucial, otherwise OpenWrt cannot boot.
4. Below, select and upload the factory.bin image. After clicking
upgrade, the image will be flashed.
5. After flashing has finished, reboot the switch. It will now boot into
OpenWrt.
U-Boot
======
This device ships with U-boot masked as Bootbase. After the device is
powered, a DRAM test is performed. Spamming $ during that test will drop
you into a shell after test finished. You'll have a limited command set
at first.
Unlocking the shell with [1] or [2] will give you a normal U-boot
command set. From here, you can perform initramfs boot or recovery.
Initramfs boot:
> loady 0x82000000 + go 0x82000000
Recovery:
> upgradeY image2 0x82000000 115200
Return to stock firmware
========================
1. Download the firmware for the switch from Zyxel website.
2. Unzip the download, there should be a .bin file with a alphanumeric
name.
3. Upload this file to running OpenWrt.
4. Run (use -F since the image doesn't have image metadata):
> sysupgrade -F <stock-firmware>.bin
5. Wait for the sysupgrade to succeed and the switch reboot. At the next
boot, ZyNOS should come up again.
Jonas Jelonek [Thu, 30 Apr 2026 21:32:29 +0000 (21:32 +0000)]
realtek: dts: rtl930x: add pinctrl and pinmux for UART1
RTL930x SoCs have a second serial interface UART1 which is exposed on
dual-function pins shared with JTAG. The SoC defaults to the JTAG
functionality after reset. Similar to existing pinmux registers, there's
a separate register for that where a selector decides about JTAG vs
UART.
Add a now pinctrl node for that register and a pinmux node to enable
UART1 functionality. Reference the pinmux in the (by default disabled)
uart1 node. Without this, UART1 doesn't work when it is actually needed.
This is e.g. the case with some PoE-capable switch where the PSE MCU
communicates with the SoC via UART instead of I2C.
Jonas Jelonek [Tue, 28 Apr 2026 20:53:52 +0000 (20:53 +0000)]
realtek: make Zyxel XMG1915-10E generic for whole family
The XMG1915 is a switch family with multiple variants sharing nearly
all hardware (same SoC, PHYs, SFP cages, LEDs) and mainly differing
in PoE and minor details.
In preparation for adding further variants, move the bulk of the
device tree into a shared rtl9302_zyxel_xmg1915.dtsi and reduce the
per-device dts to the device identity (compatible, model) plus any
variant-specific nodes.
For images, factor a Device/zyxel_xmg1915 template holding the shared
build settings so per-device definitions only need DEVICE_MODEL.
Jonas Jelonek [Tue, 28 Apr 2026 21:21:23 +0000 (21:21 +0000)]
realtek: support web vendor upgrade for XMG1915-10E
So far the XMG1915-10E used the rt-loader-bootbase recipe which
produces a separate loader.bin and only allows installation/upgrade
from the CLI side, not via the Zyxel web UI.
Switch to the standard zyxel_zynos image recipe shared with the other
Zyxel rtl930x devices. The loader now lives inside the 'factory'
parent partition introduced in the previous commit, so the resulting
single sysupgrade image can be flashed both from the vendor web UI
and via sysupgrade. Hook the device into the existing xs1930 case in
platform.sh which sets PART_NAME=factory and calls default_do_upgrade.
This makes the installation and revert procedure in 94607d6285cc
("realtek: add support for Zyxel XMG1915-10E") mostly obsolete and
partly not working anymore (due to different build images that are
emitted).
Jonas Jelonek [Tue, 28 Apr 2026 21:00:24 +0000 (21:00 +0000)]
realtek: fix Zyxel XMG1915-10E partition layout
When support for this device was added, the partition layout was defined
in a way that doesn't use space as intended and wastes quite a lot of
it.
(1) firmware partition starts at offset 0x1260000. This is the second
partition/B partition in the A/B scheme used by Zyxel. While the
commit mentions the image is written to A, the firmware partition
is defined in the B space.
(2) firmware partition only ~16MB in size. The device has a total of
32MB of flash. The vendor uses an A/B scheme but OpenWrt doesn't use
it. Thus, OpenWrt can make use of the full available space.
(3) loader partition too big. Other devices using rt-loader explicitly
in a partition use a size of 0x10000. This is more than enough
already. The device here uses 0x30000 which is mostly wasted.
Those issues are fixed accordingly. While at it, move partitions 'loader'
and 'firmware' into a parent partition 'factory'. This is a preparation
for adding web upgrade support for this device.
Fixes: 94607d6285cc ("realtek: add support for Zyxel XMG1915-10E") Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23218 Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now there is a O(n) loop that looks up a port for a
given bus/phy combination. This is slow for high port count
devices (RTL839x and RTL931x). Implement a efficient reverse
lookup table for that.
While we are here adapt tiny bits of the documentation to
better reflect the driver logic after the recent refactoring.
realtek: mdio: change prefix from "rtmdio_" to "rtmd_"
The long prefix distracts the reader from the real variables,
functions and defines. Shorten it to "rtmd_" that is not
used by any other upstream driver.
- low level functions do a bulk write
- high level functions have device specific structures
Turn this upside down and hide the register logic in the low
level functions. To achieve this:
- add a register map to each device
- change the low level write to use this map
- use only one common unique command structure
- use the command structure in the high level functions
While we are here fix the RTL838x access patterns. The read
functions do not need to set the bitmask.
Be consistent with the rest of the code and make clear when the
driver accesses ports. For this rename num_phys to num_ports.
Additionally make the device specific port numbers a define and
use them in the configuration structure.
Hauke Mehrtens [Sun, 3 May 2026 20:21:05 +0000 (22:21 +0200)]
libubox: update to Git HEAD (2026-05-03)
895f92164b66 uloop: add ULOOP_PRIORITY support for EPOLLPRI events f9b1f3ff17ba uloop: revert my flag changes from the ULOOP_PRIORITY change 2982bfb1c325 blob: fix wrong type for realloc result in blob_buffer_grow() 78c20f6c8579 json_script: convert recursive __json_script_file_free() to iterative e7c13bf8cbca usock: fix off-by-one in nanosecond normalization in poll_restart() 68b3f1588de4 uloop: usock: add error checking for fcntl and remove duplicate include 03821f942c49 uloop: fix undefined behavior in signal bit operations for signals > 32 e6e6fd83e26d blobmsg: fix policy name length overflow and add bounds check in blobmsg_parse() d30b9cc1a02d usock: fix integer overflow in timeout calculations 406e342bb900 udebug: fix double off-by-one in udebug_entry_vprintf() 700eca0bac66 blobmsg_json: fix integer overflow in blobmsg_puts() 6351fe552162 blobmsg_json: floor strbuf size and tighten the post-format guard 58b6543f1b25 blobmsg: fix unsigned integer overflow in blobmsg_alloc_string_buffer() d7a3ae699df0 blobmsg: use correct byte-order macro when setting BLOB_ATTR_EXTENDED 23c6618a5b90 blobmsg_json: fix double format string to avoid truncation and data loss 1edf1d704e76 jshn: fix integer overflow and type confusion in jshn_parse_file 9b488010c4a7 utils: fix integer overflow in __calloc_a() 40a87f734b94 blob: fix integer overflow in buffer growth functions 02fccb465651 blob: use size_t for blob_memdup() length 0fa612ca08f7 json_script: avoid alloca() on attacker-controlled pattern length 8c9862b6921b blobmsg: fix integer overflow in blobmsg_realloc_string_buffer() 5fbef5bb94fb ustream: avoid INT_MAX overflow on malloc in ustream_vprintf() 1501e60e5554 md5: detect read errors in md5sum() instead of returning a bogus hash
x86/base-files: add support for CloudGenix ION 2000
The CloudGenix ION 2000 is a discontinued entry-level SD-WAN appliance,
a rebranded Lanner FW-7525 based on the Intel Atom C2XXX family of processors
with 4 integrated GbE ports and 2 additional I210 GbE ports. It can often be
found on eBay starting below USD 30.
The device's BIOS is password-protected, and the password somehow hasn't leaked,
but OpenWrt can be successfully booted by overwriting the stock OS on the boot
media.
See https://forum.openwrt.org/t/report-openwrt-on-cloudgenix-ion-2000/249315
for more details.
The two I210 NICs and integrated NICs are pinned to their
PCIe paths to ensure consistent interface ordering matching
the physical port layout with eth0 assigned to controller and
acting as WAN with remaining devices as LAN.
Rosen Penev [Thu, 4 Dec 2025 03:15:05 +0000 (19:15 -0800)]
ath79: fix label-mac-device for wmac
It appears 683-of_net-add-mac-address-to-of-tree.patch relies on the
mac-address nvmem property being present. wmac itself doesn't need it as
it takes it from the eeprom but label-mac-device needs it.
Ahmed Naseef [Thu, 19 Mar 2026 11:55:28 +0000 (15:55 +0400)]
econet: en7528: add USB support
Add USB host support for EN7528 SoC:
- New phy-en7528-usb driver with U2 slew rate calibration and U3
RX impedance tuning, based on GPL vendor code and the Airoha
AN7581 USB PHY driver
- xHCI LTSSM timing quirk for TD 6.5 compliance (patch 915)
- USB PHY and xHCI DTS nodes with IPPC register mapping
- VBUS power via regulator-fixed for DASAN H660GM-A
- Enable USB, xHCI, PHY, and regulator kernel configs
kmod-sound-midi2 expects sound/core/snd-ump.ko, but
CONFIG_SND_UMP=y builds it in-kernel rather than as
a module. Replace the forced built-in setting with
plain CONFIG_SND_UMP so the module can be packaged
correctly.
mediatek: add support for Qihoo 360T7 (UBI layout)
This commit adds support for Qihoo 360T7 (UBI layout).
Aims
----
1. +20 MB additional free space for the packages
2. More reliable storage for the factory and fip partitions (in UBI)
Install (from non-UBI OpenWrt)
------------------------------
1. Navigate http://192.168.1.1/ and download mtd backups
2. Upgrade OpenWrt with installer initramfs image (force upgrade, don't
keep settings). Wait until OpenWrt reboots and until installer:
- Prepare new factory partition
- Format new ubi
- Make ubi volumes
- Write new fip and bl2
3. Navigate http://192.168.1.1/ and Upgrade with OpenWrt 'sysupgrade.bin'
image (don't keep settings)
Qingfang Deng [Fri, 24 Apr 2026 01:44:32 +0000 (09:44 +0800)]
kernel: enable static key
Enable static key (jump label) on all supported architectures. This
lowers overhead and stress on the branch prediction of the CPU and
generally makes the kernel faster.
mediatek,mtd-eeprom predates nvmem and is being phased out.
At first glance, it looks like it's doing something useful with its
big-endian binding. However on further inspection, big-endian is handled
in the same function that mediatek,mtd-eeprom is handled. In addition,
the older mtd_read way of extracting the firmware byteswaps the data
on big endian hosts which big-endian byteswaps back. nvmem does not do
such byteswapping.
Zoltan HERPAI [Mon, 9 Feb 2026 09:34:37 +0000 (09:34 +0000)]
sunxi: add T113-S3 support
The Allwinner T113-s3 (sun8i) SoC features a dual-core Cortex-A7 ARM CPU and
128MB of DDR3 memory in the same physical package. It supports industrial
temperature ranges. Most of the IP blocks are shared with the D1/D1s core.
There are multiple variants of the SoC, which may vary in the included memory
size, with some of them including a C906 RISC-V co-processor.
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
Til Kaiser [Sun, 1 Feb 2026 15:42:46 +0000 (16:42 +0100)]
ipq40xx: refresh IPQ4019 switch patch for v6.18
Linux 6.18 adjusts the DSA/phylink integration and removes a couple of
interfaces used by the out-of-tree IPQ4019 built-in switch support.
Update the qca8k-ipq4019 patch to match the new APIs:
- move phylink callbacks to phylink_mac_ops and switch to phylink_config
[1], [2]
- adapt pcs_get_state() to the new signature [3]
- drop get_mac_eee() from dsa_switch_ops [4]
- switch platform_driver from .remove_new to .remove [5]
Til Kaiser [Fri, 27 Feb 2026 19:46:15 +0000 (20:46 +0100)]
kernel/ipq40xx: 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
A script was ran that checks the label-mac-device node to see if it has
nvmem definitions as label-mac-device requires nvmem.
This is mostly a change to make the script happy. No indended functional
difference.
Add a change to qca9533_yuncore_cpe830.dts adding an nvmem definition to
wmac. Seems to have been some kind of oversight where it's specified in
nvmem but not used. label-mac-device needs an NVMEM definition.
On 25.12.0 the device has not enough free blocks to initialize overlay.
Move the device to tiny target and consume backup with storage
partitions, which were previously unused. This operation will reclaim
~800 KiB of flash memory. OEM used storage partition for configuration,
while backup was used to store copy of U-Boot environment and copy of
calibration data.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Partially revert 5e3a602def72. Unfortunately the ethaddr value in U-Boot
environment is enclosed in double quotes which makes it longer than
ETH_ALEN, thus nvmem returns EINVAL. Switch back to handling the MAC
addresses in user space.
Fixes: 5e3a602def72 ("ath79: sitecom,wlrx100: use nvmem") Reviewed-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Rosen Penev [Sat, 2 May 2026 21:41:43 +0000 (14:41 -0700)]
ath79: use led-sources for WMAC
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Rosen Penev [Sun, 3 May 2026 21:14:32 +0000 (14:14 -0700)]
ath79: fap-221-b: revert led-sources change
Normally WMAC handles 2.4ghz on ath79 devices. Some older units though
handle 5ghz on WMAC and 2.4ghz on pcie. This can be seen by the
frequemcy limits placed on each interface.
Rosen Penev [Sat, 24 May 2025 23:02:54 +0000 (16:02 -0700)]
ath79: qca953x: use led-sources for WMAC
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Rosen Penev [Sun, 25 May 2025 00:40:41 +0000 (17:40 -0700)]
ath79: qca955x: use led-sources for WMAC
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
realtek: mach/prom: add identifiers to soc_info structure
SoC name and system type identifiers are currently separated from
the soc_info structure. This gives no benefit. Relocate that info
into the structure where it belongs.
Jonas Jelonek [Mon, 27 Apr 2026 10:34:27 +0000 (10:34 +0000)]
realtek: pcs: rtl93xx: share IP mode register write
RTL930x and RTL931x program the same physical SerDes IP mode field
(page 0x1f reg 0x09, bits 11:7 hold the 5-bit mode value, bit 6 is
the "force mode" enable), but did so via two unrelated code paths:
RTL930x kept the force bit separate from the value in a __set helper,
while RTL931x had it baked into each switch-case constant.
Add a shared rtpcs_93xx_sds_set_ip_mode() that takes the rtpcs_sds_mode
enum, looks up the 5-bit value from the existing sds_hw_mode_vals
table, and writes value | force-bit in one place.
Convert both variants:
- RTL930x: drop __rtpcs_930x_sds_set_ip_mode and the manual table
lookup; __rtpcs_930x_sds_get_ip_mode is replaced by the shared
rtpcs_93xx_sds_get_ip_mode, which reverse-looks the raw register
value up in sds_hw_mode_vals[] and returns the matching enum
rtpcs_sds_mode (or -ENOENT for an unmapped raw value). The
wrapper that orchestrates power, CMU, state machine and rx-reset
around the mode write is renamed to rtpcs_930x_sds_apply_ip_mode
for clarity.
- RTL931x: drop the per-mode switch and the leftover pr_info debug
print; rename the symerr-clear + MAC-OFF + IP-mode-write wrapper
to rtpcs_931x_sds_apply_ip_mode.
rtpcs_930x_sds_reconfigure_to_pll() now goes through the new shared
get/set helpers: it saves the current IP mode as an enum on entry
and restores it via the enum-taking setter after the PLL reconfigure.
This changes behavior by mapping the raw mode setting through the
hardware mode table, effectively blocking unknown modes which might be
set by bootloader or somewhere else. This is intended and might uncover
unknown behavior instead of hiding it.
As a side-effect, QSGMII is now properly set too for RTL931x. Most code
paths anyway already had support for this mode, but it was missing from
the mode setting.
Christoph Krapp [Mon, 4 May 2026 07:23:13 +0000 (09:23 +0200)]
ath79: add calibration variant for TP-Link EAP225-Wall v2
Now that we have a board file, add calibration variant for TP-Link
EAP225-Wall v2 and add ipq-wifi package for it.
Tested-by: Alexander <52272120+alexxela1337@users.noreply.github.com> Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23216 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Thu, 30 Apr 2026 10:55:36 +0000 (10:55 +0000)]
realtek: image: reset COMPILE between devices
Device/zyxel_zynos sets COMPILE := loader-$(1).bin to drive the
standalone rt-loader build, but include/image.mk's Device/Init does
not reset COMPILE between TARGET_DEVICES iterations. When a non-zynos
device follows a zynos device, the stale COMPILE entry survives and
Device/Build/compile registers a second recipe for the previous
device's loader-*.bin target. Make warns about the override and the
second (wrong) recipe wins.
Reset COMPILE in Device/Default so each device starts with a clean
slate.
Jonas Jelonek [Thu, 30 Apr 2026 10:54:33 +0000 (10:54 +0000)]
realtek: image: pin FLASH_ADDR per device
FLASH_ADDR is referenced inside Build/rt-loader-standalone but is not
listed in DEVICE_VARS, so include/image.mk's Device/Export does not
emit a per-target FLASH_ADDR := <value> assignment for the standalone
loader recipe. At recipe expansion time $(FLASH_ADDR) therefore
resolves to whatever value the last device in TARGET_DEVICES set
globally, which is not necessarily the value belonging to the loader
being built.
This currently happens to produce correct binaries only because every
device that sets FLASH_ADDR within a given subtarget shares the same
value, so the leaked global matches by coincidence.
Add FLASH_ADDR to DEVICE_VARS so each loader recipe captures its own
device's address.
Zoltan HERPAI [Tue, 5 May 2026 22:41:54 +0000 (22:41 +0000)]
starfive: 6.18: update LED aliases
Between 6.12 and 6.18, a 'blank' led_status_power has been added into
jh7110-common.dtsi. Update the patches responsible for adding the LED
aliases and add functionality for this LED entry.
The mdio driver has found a simple way to handle phy addresses
for all devices with upstream kernel defaults. Remove all unneeded
hacks from the corresponding patch and reword it.
While we are here increase DSA_MAX_PORTS to 56 to match RTL931x.
- mdio bus 0 serves ports 0..23
- mdio bus 1 serves ports 24..51
This is baked into hardware and cannot be changed during mdio driver
setup with any register write. With the recent changes the driver
handles ports, phys and busses in a more logical way. So a port X
is assigned to a bus Y and a phy Z (on that bus). This gives a
mapping like
- port 16 <=> bus 0, address 16
- port 32 <=> bus 1, address 8
This unique assignment is used in the mdio driver as follows:
- Request to read bus 1, address 8
- Lookup corresponding port = 32
- Read from port 32
Looking at RTL839x it becomes clear that bus/phy => port lookup can
be achieved in multiple different ways. The simple reason is, that
for this device the driver cannot setup the smi topology. It is
baked into the hardware. So adding a "virtual" second bus does not
change the hardware access but allows to keep phy addresses below 32.
Making an example
mdio_bus0 {
PHY_C22(40, 40)
}
resolves to port 40. But the same can be achieved with
mdio_bus1 {
PHY_C22(40, 16)
}
In the first case the kernel sees bus/phy = 0/40 and in the second
case it sees bus/phy = 1/16. Both result in the access to the same
phy device on hardware port 40.
Use this analogy for RTL839x devices to match the real hardware
topology. For this change the existing dts and
- activate mdio bus 1 in rtl839x.dtsi
- rearrange devices with ports 24..51 to make use of bus 1
The lm75 alert polarity active-high patch has been accepted upstream.
Replace the downstream version. Additionally add an upstream bugfix
that was identified during the implementation.
Edward Chow [Mon, 27 Apr 2026 03:13:51 +0000 (11:13 +0800)]
mpc85xx: unify wrapper address of simple image devices
The wrapper address of simple image devices should have been changed
at commit 6a8b831 , but only TL-WDR4900 and BR200-WP are changed at
that time, and now the wrapper address changes are split among patches
for specific devices. More importantly, commit 6a8b831 forgot to
change Enterasys WS-AP3715i, causing
https://github.com/openwrt/openwrt/issues/23112 .
This commit will gather the change of wrapper address of simple image
devices into a dedicated patch file.
Tested: Both WS-AP3715i and TL-WDR4900 v1 boot well.
Fixes: https://github.com/openwrt/openwrt/issues/23112 Signed-off-by: Edward Chow <equu@openmail.cc> Link: https://github.com/openwrt/openwrt/pull/23121 Signed-off-by: Robert Marko <robimarko@gmail.com>
Edward Chow [Wed, 29 Apr 2026 21:52:10 +0000 (05:52 +0800)]
mpc85xx: ws-ap3715i: use libdeflate-gzip for kernel
The simpleImage contains a payload already compressed with lzma-based
xz (by default), so further compressing it with lzma will often make
the result larger. On the contrary, compressing these simpleImages
with gzip can make the result smaller, so replace lzma with
libdeflate-gzip to compress kernel for ws-ap3715i.