Chukun Pan [Sun, 25 Jan 2026 15:18:02 +0000 (23:18 +0800)]
generic: backport MSI affinity support for DW PCIe
Currently, the DesignWare PCIe driver cannot configure interrupts on
SoC that do not support MSIX. All MSI interrupts are handled by CPU0.
Backport MSI affinity support for the PCI dwc driver from linux-next,
so now we can adjust MSI interrupts to other CPU cores.
Tested on HINLINK H28K (RK3528) and OrangePi R2S (Ky X1).
Andrew LaMarche [Wed, 22 Apr 2026 12:24:10 +0000 (12:24 +0000)]
kernel: crypto: fix build with Linux >= 6.18 after octeon-md5 removal
Linux commit c9e5ac0 ("lib/crypto: mips/md5: Migrate optimized code into
library") removed the MIPS-Octeon-specific MD5 implementation
(octeon-md5.ko) and replaced it with an optimized library implementation
in lib/crypto.
As a result, CONFIG_CRYPTO_MD5_OCTEON and the module
arch/mips/crypto/octeon-md5.ko no longer exist in kernels >= 6.18.
Andrew LaMarche [Tue, 21 Apr 2026 13:18:04 +0000 (13:18 +0000)]
kernel/octeon: 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
Jan Hoffmann [Thu, 23 Apr 2026 14:58:40 +0000 (16:58 +0200)]
generic: net: phy: realtek: don't disable MDIO address 0 for PHY in SFP module
At least the XikeStor SKT-2.5G-100M SFP module seems to internally use
MDIO address 0 to access the PHY. This module allows accessing PHY
registers using Rollball protocol on address 0x51, and also provides
read-only C22 access on address 0x56. However, after disabling the
PHYAD0 configuration bit, only 0xffff can be read via both methods
(except for MMD device 30 which can still be accessed).
Since having MDIO address 0 enabled shouldn't do any harm on SFP modules
just leave the configuration bit alone in that case.
After the RTL8261N asserts a reset, the MDIO bus becomes temporarily
unavailable during the chip's reinitialization sequence. Any subsequent
read or write issued before the PHY has stabilized will fail.
Add a 30ms delay after triggering the reset to ensure the chip is reachable
via MDIO before resuming communication.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/23076 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Sven Eckelmann [Fri, 24 Apr 2026 06:50:21 +0000 (08:50 +0200)]
kernel: rtl8261n: always configure as USXGMII
In the past, all the configuration of SerDes and PHYs on the realtek
switches were done using u-boot (`rtk init`). But since RTL930x switched
to SerDes configuration under Linux, the SoC side is no longer using the
Realtek-proprietary variant of USXGMII. The communication to the RTL8261N
PHYs on those switches broke because of this incompatibility.
Enabling the full initialization on `CONFIG_MACH_REALTEK_RTL` converts also
the PHY side to the standard USXGMII and therefore ensures that both sides
speak the same dialect.
Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/23076 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Sven Eckelmann [Fri, 24 Apr 2026 06:50:21 +0000 (08:50 +0200)]
kernel: rtl8261n: drop unreachable PHY register patch
The PHY register patch in question is gated by `CONFIG_MACH_REALTEK_RTL`,
has no documented/expected behavior, and is in practice unreachable:
`phy_patch()` is only called from `rtkphy_config_init()`, which is exits
(too) early for `CONFIG_MACH_REALTEK_RTL` builds.
Remove it as a cleanup step before enabling standard USXGMII configuration
for these PHYs.
Fixes: b77fa45d1278 ("kernel: fix rtl8261n driver for realtek") Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/23076 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Carlo Szelinsky [Sat, 11 Apr 2026 15:11:25 +0000 (17:11 +0200)]
realtek: rtl930x: add Hasivo S600WP-5GT-2SX-SE
This commit adds support for Hasivo S600WP-5GT-2SX-SE switch.
Device specification
--------------------
SoC Type: Realtek RTL9303
RAM: 128MB DDR3 SDRAM
Flash: Fudan FM25Q128A (16 MB)
Ethernet: 5x RTL8221B 10/100/1000/2500Mbps PHY (RJ45)
2x SFP+ 10G (I2C/DOM via bit-banged GPIO)
LEDs: 1x power green (no control)
1x system green (via RTL9303 GPIO)
3x RJ45 LEDs/port (HC595 shift regs on LED SPI)
1x Green (1G link)
1x Green (10M/100M link)
1x Orange (2.5G link)
2x SFP+ LEDs/port (HC595 shift regs on LED SPI)
1x 10G link
1x 1G link
Button: Reset
USB ports: None
Bootloader: Realtek U-Boot 2011.12
PoE: 1x HS104PTI for 802.3af/at/bt PoE (driver
will follow in a separate patch)
Installing OpenWrt
------------------
1. UART RJ45 requires soldering a connector to the empty footprint (RJ1).
(Amphenol RJHSEE380 or similar)
2. Connect to UART 38400@8n1, using Cisco Console Rollover cable (RS232)
3. Enter bootloader by pressing esc key during boot
4. Enter password `Hs2021cfgmg`
5. Type `XXXX` to get into U-Boot
6. Increase baudrate: `setenv baudrate 115200`
7. Use serial transfer (Y modem) via minicom:
`loady 0x84f00000`
Then send the initramfs image via minicom's Y modem upload.
8. `bootm 0x84f00000`
Now you should be in OpenWrt, and can use sysupgrade to install.
Thomas Weißschuh [Thu, 23 Apr 2026 09:27:03 +0000 (11:27 +0200)]
util-linux: fix build on Linux v6.18 against musl
Backport an upstream patch to avoid usages of an undefined
AT_HANDLE_FID.
Closes: https://github.com/openwrt/openwrt/issues/23058 Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> Link: https://github.com/openwrt/openwrt/pull/23059 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Wed, 22 Apr 2026 08:33:56 +0000 (08:33 +0000)]
realtek: pcs: switch SerDes polarity to {rx,tx}-polarity
With the recent backport of the common PHY properties infrastructure
(phy-common-props and the phy_get_manual_{rx,tx}_polarity() helpers) to
OpenWrt, the generic `{rx,tx}-polarity` device tree properties are now
usable for the Realtek PCS driver. Switch the driver and all affected
boards from the local vendor-specific `realtek,pnswap-{rx,tx}` booleans
to the common properties.
Add a `config_polarity` SerDes op (implemented by RTL930x and RTL931x;
RTL838x/RTL839x polarity support not yet added) and a generic wrapper
that resolves the requested polarity via phy_get_manual_{rx,tx}_polarity()
and dispatches to the op. Variants without the op silently accept the
default polarity but warn when a non-default polarity is requested,
since that cannot be honored.
Move the polarity programming out of the variant setup_serdes callbacks
into rtpcs_pcs_config, so it runs before setup_serdes. This matches the
ordering used by the vendor SDK, which configures polarity first.
Update all board DTS files that previously used `realtek,pnswap-{rx,tx}`
to the new `{rx,tx}-polarity = <PHY_POL_INVERT>` property, and select
PHY_COMMON_PROPS from Kconfig.
Each SerDes now retains its DT node for later polarity lookup. Use
for_each_child_of_node_scoped for the iterator, and register a
devm_add_action_or_reset for each stored reference so it is released on
unbind or probe failure.
Zoltan HERPAI [Thu, 25 Dec 2025 23:11:00 +0000 (23:11 +0000)]
kernel/sunxi: 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
Andre Heider [Thu, 23 Apr 2026 08:38:06 +0000 (10:38 +0200)]
base-files: ipcalc.sh: get rid of `basename` dependency
The netifd/dhcp flow uses this, and as uxc mounts netifd in a
container, this allows not mounting `basename` for just a usage.
References: https://github.com/openwrt/procd/pull/34 Suggested-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Andre Heider <a.heider@gmail.com>
Shiji Yang [Fri, 10 Apr 2026 15:07:02 +0000 (23:07 +0800)]
lantiq: refresh 6.18 kernel config files
CONFIG_PAGE_BLOCK_MAX_ORDER was set to 10 as the page size is 4k.
All other kernel symbols are automatically refreshed by
`make kernel_oldconfig CONFIG_TARGET=target` and
`make kernel_oldconfig CONFIG_TARGET=subtarget`.
Oskari Lemmela [Fri, 19 Nov 2021 05:36:22 +0000 (07:36 +0200)]
ath79: add support for MikroTik RouterBOARD 960PGS
This patch adds support for the MikroTik RouterBOARD 960PGS (hEX
PoE/PowerBox Pro) router. The device has a USB 2.0 port and an SFP port for
adding optical fiber connectivity. The ports 2-5 can power other PoE
capable devices with the same voltage as applied to the unit.
Specifications:
- SoC: Qualcomm Atheros QCA9557
- Flash: 16 MB (SPI)
- RAM: 128 MB
- 1x Ethernet SFP: 1000
- 1x Ethernet RJ45: 10/100/1000 port with passive POE in
- 4x Ethernet RJ45: 10/100/1000 ports with 802.3af/at PoE out
- 1x USB 2.0 host port
- 1x reset button
See [1] and [2] for more details.
Flashing:
TFTP boot initramfs image and then perform sysupgrade. Follow common
MikroTik procedure as in https://openwrt.org/toh/mikrotik/common.
Chester A. Unal [Tue, 24 Feb 2026 13:39:36 +0000 (15:39 +0200)]
ath79: mikrotik: compile SWCONFIG and AR8216_PHY as modules
Unset the SWCONFIG symbol and AR8216_PHY which selects SWCONFIG. Add
kmod-switch-ar8xxx, which enables AR8216_PHY, to DEFAULT_PACKAGES for the
subtarget. With this, swconfig driver will be now compiled as a module, as
kmod-switch-ar8xxx selects kmod-swconfig.
Refresh the config-default file for ath79/mikrotik while at it.
This change makes it possible to disable the swconfig driver for MikroTik
RouterBOARD 960PGS (hEX PoE/PowerBox Pro).
Signed-off-by: Chester A. Unal <chester.a.unal@arinc9.com>
imx: cortexa9: ventana, fix profiles names in profiles.json
These two image profiles overwrite DEVICE_NAME making the two image
profiles appear with the same name "ventana" in the "profiles.json"
mixing ramdomly the two profiles.
Use BOARD_NAME instead to keep the two profiles names unique (orginal
DEVICE_NAME) hence generating a coherent "profiles.json".
Since there are image recipes hardconding DEVICE_NAME, change them to use
BOARD_NAME if defined, in order to preserve the previous names used in
those recipes.
Fixes: cbc8bcfbaa71fe0928bf07d29ec0fe6217fd51ad ("imx6: image: use vendor_model scheme") Reported-by: Eric Fahlgren <ericfahlgren@gmail.com> Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com> Link: https://github.com/openwrt/openwrt/pull/22994 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tianling Shen [Thu, 26 Mar 2026 06:05:35 +0000 (14:05 +0800)]
kernel: backport Motorcomm YT6801 PCIe ethernet driver support
Motorcomm YT6801 is a PCIe ethernet controller based on DWMAC4 IP. It
integrates an GbE phy, supporting WOL, VLAN tagging and various types
of offloading. It ships an on-chip eFuse for storing various vendor
configuration, including MAC address.
The PM and plat_data functions were slightly modified to build with
current kernel.
Stop overriding CCACHE_COMPILERCHECK from rules.mk and rely on
ccache's default, which hashes the compiler binary's mtime and
size.
For a local tree that is enough: the toolchain only changes when
it is rebuilt, and a rebuild updates mtime and size. Users who
want a stricter check can still set CCACHE_COMPILERCHECK in their
environment.
CI does not depend on this export either. The workflow writes a
secondary ccache.conf with
compiler_check=string:<toolchain-commit-sha>
so the cache key is tied to the toolchain source revision. That
is both stricter than the previous "%compiler% -v -c" setting
and portable across runners, where compiler mtimes would not
match after restoring a cache archive.
qualcommax: ipq50xx: ax6000: enable pcie1 for QCA9887
The Xiaomi AX6000 has three radios:
- IPQ5018 integrated 2.4 GHz (ath11k AHB, wifi0)
- QCN9024 on PCIe0 (ath11k PCI, QCA8074-class 5 GHz)
- QCA9887 on PCIe1 (ath10k, 5 GHz)
The DTS previously kept pcie1 disabled because the controller
could not bring the link up. The real cause was the PERST GPIO
polarity: the stock device-tree uses GPIO_ACTIVE_HIGH on GPIO18
for the QCA9887 card, while OpenWrt had GPIO_ACTIVE_LOW, leaving
the card held in reset.
With the correct polarity the PCIe1 link trains and the QCA9887
enumerates at 01:00.0. ath10k loads firmware-2.bin, registers
phy0 with mac80211, and provides a functional 5 GHz AP.
Tested on a reworked Xiaomi AX6000 with QCA9887 soldered in.
All three radios enumerate, load firmware and beacon
successfully; scan, association and data traffic confirmed on
each radio.
The EXTERNAL_SFP_PHY macro is very strange. It has attributes
sfp and media but is not linked to any SFP definition. There
is nothing that the kernel can evaluate better than the classic
PHY_C22 macro.
Remark! For the current D-Link DGS-1210 consumers this macro
should be converted to a PHY_C22_SFP in the future. As of now
there is no hardware to identify the proper gpios and define
and verify the corresponding SFP ports. Add a TODO comment
where needed.
realtek: dts: convert EXTERNAL_SFP_PHY_FULL to PHY_C22_SFP
Several EXTERNAL macros have been removed in the past. There is
no need to distinguish if a phy is built into the SoC or is
attached externally.
Do the same for EXTERNAL_SFP_PHY_FULL. This macro denotes a phy
that has a SFP port attached to it. This is usually RTL8214FC
based. To be consistent with other macros name it PHY_C22_SFP.
While we are here make use of the new port/phy notation.
So PHY_C22_SFP(p, n, s) gives
- p: the overall port number
- n: the phy address on the current bus
- s: the sfp identifier
Import pending series introducing support for standalone PCS drivers.
This has previously already been used by the airoha target, and is
also the base for the closer-to-upstream patches for MediaTek MT7988
10G SerDes support.
In order to not having to diverge from upstream also backport series
for standardized handling for PHY and PCS SerDes pair polarity.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Nick Hainke [Thu, 2 Apr 2026 15:57:40 +0000 (17:57 +0200)]
kenrel: crypto: fix build with Linux >= 6.18 after md5-ppc removal
Linux commit 09371e1349c9 ("lib/crypto: powerpc/md5: Migrate optimized code into library")
removed the PowerPC-specific MD5 implementation (md5-ppc.ko) and
replaced it with an optimized library implementation in lib/crypto.
As a result, CONFIG_CRYPTO_MD5_PPC and the module
arch/powerpc/crypto/md5-ppc.ko no longer exist in kernels >= 6.18.
Nick Hainke [Sat, 11 Apr 2026 09:56:05 +0000 (11:56 +0200)]
kernel/mpc85xx: 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
Add f2fs support into the kernel, otherwise the overlay f2fs
will not be created.
[ 7.611817] loop0: detected capacity change from 0 to 212992
[ 7.638471] loop0: detected capacity change from 212992 to 206208
[ 7.757259] mount_root: failed to mount -t f2fs /dev/loop0 /tmp/overlay: No such device
Zhihao Xu [Tue, 17 Feb 2026 12:11:40 +0000 (20:11 +0800)]
kernel/starfive: 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
Paul Spooren [Mon, 20 Apr 2026 11:46:13 +0000 (19:46 +0800)]
scripts: add git_commit to profiles.json
Right now we only have the special getver.sh output (i.e. r32802-f505120278)
instead of the actual, full git hash. Offer the full hash for downstream
tooling, specifically the KernelCI.
uboot-at91: fix wrong BUILD_DEVICES for sama5d4_xplained_nandflash
The sama5d4_xplained_nandflash target incorrectly references microchip_sama5d3-xplained as its BUILD_DEVICES value.
This appears to be a copy-paste error, as all other SAMA5D4 Xplained targets (e.g. mmc and spiflash) correctly use microchip_sama5d4-xplained. The target name itself also clearly refers to the SAMA5D4 platform.
In addition, the SAMA5D3 Xplained and SAMA5D4 Xplained boards use different NAND flash hardware and configurations, so pointing the nandflash target to a SAMA5D3 device is incorrect and may lead to invalid builds or runtime issues.
Fix the inconsistency by updating BUILD_DEVICES to microchip_sama5d4-xplained, aligning the nandflash target with the rest of the SAMA5D4 definitions and ensuring the correct device mapping.
Daniel Pawlik [Mon, 20 Apr 2026 11:29:29 +0000 (13:29 +0200)]
generic: 6.18: drop stale hunk of Filogic SerDes patch
Daniel Pawlik figured out that a stale patch hunk breaks one of the
two 10G SerDes PCS ports of MT7988. Remove the hunk to make 10G
Ethernet work on both SerDes PCS with Linux 6.18.
Testing was done using a Aquantia AQR113C SFP+ module.
Signed-off-by: Daniel Pawlik <pawlik.dan@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The console port is a 4-pin header reachable without opening case.
Looking at the front port-side of the device, turn the device 90 degrees
clockwise. On this side, there's a rectangular opening in the honeycomb
structure. Pinout is (from left/front to right/back): GND RX TX VCC
Hardware quirks
===============
* The SFP signals RX_LOS, MOD_ABS and TX_FAULT do not have dedicated GPIO
lines each. Instead, there's a multiplexer (using GPIO12 and GPIO14)
which - depending on its state - connect this single GPIO line to RX_LOS,
MOD_ABS or TX_FAULT (GPIO19 for SFP1, GPIO27 for SFP2). This requires
a special adapter driver (which is backed by a gpio-mux) that makes
this hardware design and Linux' SFP core work together.
* SFP slots are disabled by default. GPIO6 and GPIO7 seems to be gates
for SFP1 and SFP2 respectively. The need to be pulled low to make SFP
modules work (i.e. respond to I2C requests and pass GPIO signals).
* Fan can only be set to SLOW or FAST mode, no real speed/PWM control.
Disclaimer
==========
PoE not yet supported.
Flashing OpenWrt will overwrite BootExtension + ZyNOS. BootExtension
functionality (e.g. initramfs boot as mentioned below) 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.
Initramfs boot
==============
NOTE: You need to use Xmodem transfer, the bootloader doesn't support
Ymodem nor any networking.
This only works as long as the default ZyNOS firmware is
installed.
1. Connect to the switch using serial and interrupt the boot process
to enter debug/recovery mode.
2. You need to unlock the bootloader. Use known methods [1] and [2] to
obtain the unlock code and unlock the bootloader with:
> ATEN 1,<unlock_code>
3. Upload the initramfs image using Xmodem:
> ATUP <address>,<file_length>
<address>: you may use any RAM address >= 0x80300000
<file_length>: length of image in bytes
4. After the transfer has finished, boot the image with:
> ATGO <address>
5. Wait for OpenWrt to boot. At this stage, it might be wise to create a
backup/dump of the Flash partitions.
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.
Recovery
========
The Bootbase loader is actually a modified U-Boot variant. You can enter
it by spamming $ during the DRAM test.
The U-Boot shell can be unlocked with [1] and [2]. Note that the command
is slightly different, using a space instead of a comma, and lowercase:
> aten 1 <unlock_code>
You should now have more-or-less a standard RTK-U-boot shell from where
you can upload and write a new image to flash. Use e.g.: