The nRESET pins of the RTL8224 PHY on the MCX3 are wired to GPIO6 of the
SoC, but this was never described in the devicetree.
Commit c99a30668d5f ("realtek: add RTL8224 initialization to Realtek
driver") introduced support for reinitializing RTL8224 PHYs, and commit 084da38a2e74 ("realtek: mdio: activate multiple busses") allowed the MDIO
bus provider load the devicetree properties to the bus, including reset
descriptors. With both in place, a bus level PHY reset via the hardware pin
is now correctly triggered before reinitialization.
Add the missing reset-gpios property so the PHY can be reset via the
hardware pin.
Remove legacy hack patch, switch mt7621 crypto node to the intended
Safexcel insecure EIP93 compatible string and simplify crypto module
packaging to use the inside-secure eip93 driver.
FIPS 140-3 recommends that all crypto implementations should be tested
before first use. Testmanager performs initial tests based on existing
test vectors. Not all algorithms have defined test vectors, so to improve
this situation, this commit backports recently added test vectors for
some cipher suites.
These vectors were calculated using a software implementation and then
double-checked on Mediatek MT7981 (safexcel) and NXP P2020 (talitos).
Both platforms passed self-tests.
realtek: arch: rtl-otto: add rtl9607 model info support
Add the registers, family id and cpu port defines to the mach header.
Since RTL96xx SoCs has additional "subtype" info, add the respective
property to soc_info struct to be used in prom file.
The same way as rtl838x, the chip_info register requires 0xa to be
written. Similarly, 0xb must be written to get the subtype info.
There doesn't seem any check for testchip in RTL96xx so, we ignore it.
Add subtype information to set_system_type function if it is present
using the added subtype variable.
There are some RTL9607 chips out there with 512MB so add the check
for RTL9607 in the prepare_highmem. The registers are the same as
in RTL9300 so nothing else need to be changed.
Add patches to improve support for using 3rd-party DSA switches
like MaxLinear MxL862xx with MediaTek's mtk_eth_soc being the
conduit. This involves reorganizing hardware queues to avoid
overlap (currently dp->index is used -- if there is more than one
DSA switch this is problematic), and correctly programming flows
of the non-MTK DSA users ports in the PPE offloading engine.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Paweł Owoc [Mon, 27 Apr 2026 11:57:28 +0000 (13:57 +0200)]
modules: video: Fix DRM client lib dependency
Fix dependency for kmod-drm-client-lib module:
error: recursive dependency detected!
symbol LINUX_6_18 is selected by PACKAGE_kmod-drm-client-lib
symbol PACKAGE_kmod-drm-client-lib is selected by LINUX_6_18
Fixes: e75ba35ed837 ("modules: video: introduce DRM client setup module") Signed-off-by: Paweł Owoc <frut3k7@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23124 Signed-off-by: Robert Marko <robimarko@gmail.com>
Shiji Yang [Mon, 27 Apr 2026 11:42:55 +0000 (19:42 +0800)]
bcm27xx: update irq-msi-lib.h header path
Fix build error:
drivers/irqchip/irq-bcm2712-mip.c:14:10: fatal error: irq-msi-lib.h: No such file or directory
14 | #include "irq-msi-lib.h"
| ^~~~~~~~~~~~~~~
Fixes: ba7aa2a97153 ("generic: backport MSI affinity support for DW PCIe") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/23125 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Thu, 23 Apr 2026 11:28:45 +0000 (11:28 +0000)]
realtek: pcs: rtl931x: drop USXGMII gating in setup_serdes
The USXGMII_10GDXGMII and USXGMII_10GQXGMII early-return was added
when the submode register was not yet programmed, making those modes
effectively unconfigurable. With the submode now wired up at probe
time and written from the set_mode path, the gating is no longer
needed.
Keep the XSGMII gate - RTL8218D/E bring-up through the proprietary
10G SGMII path is still unimplemented - and rewrite the surrounding
comment accordingly.
Complete the USXGMII submode table with the four values that were
missing so far:
0x01 10GDX (2 x 5G)
0x03 5GSX (1 x 5G)
0x04 5GDX (2 x 2.5G)
0x05 2_5GSX (1 x 2.5G)
Together with the existing 10GSX (0x00) and 10GQX (0x02) this covers
all six USXGMII modes the driver declares. Add a corresponding mapping
to the hw_mode table too to cover them properly there.
Replace the switch in rtpcs_93xx_sds_apply_usxgmii_submode() with a
sparse lookup table indexed by hw_mode, using -1 as the sentinel for
modes without a submode value. Non-USXGMII modes silently no-op as
before; a USXGMII mode hitting a SerDes without an allocated submode
register now returns -EOPNOTSUPP, catching configuration mismatches
that would previously have been silently dropped.
USXGMII submode (10GSX vs 10GQX) is selected through a dedicated
register at 0x13e8, independent of the MAC and IP mode registers.
Without programming it, USXGMII-QX ports initialise as single-lane
SX and fail to link up correctly; MAC and IP mode alone are
insufficient for a working USXGMII setup.
The register packs 12 x 5-bit entries for SerDes 2..13, six per
32-bit word, non-straddling (bits 0..29 used, 30..31 padded). This
matches the available register dumps and the SDK's
reg_array_field_write() non-CROSS_REGISTERS path, which derives the
bit position as ((index - larray) % (32 / width)) * width and
accesses only a single 32-bit word. The submode values are identical
to RTL930x, so the shared RTPCS_93XX_SDS_USXGMII_SUBMODE_* defines
are reused.
Allocate the regmap_field at probe time with coordinates computed
from the SerDes ID; the regular packing needs no lookup table. Call
rtpcs_93xx_sds_apply_usxgmii_submode() from the set_mode dispatcher
after set_ip_mode - the helper's null-guard and mode filter leave
non-USXGMII paths unchanged.
Its original commit message fails to mention that the commit also moves
the `#include <memory>` to an earlier position within system.h,
which is the actual change that we're after in this patch.
Building our GCC 14.3 with host GCC 16, the inclusion order starts to matter,
which is an issue that was also touched upon by the upstream commits:
9970b576b7e4 Include safe-ctype.h after C++ standard headers, to avoid over-poisoning f6e00226a4ca build: Move sstream include above safe-ctype.h {PR117771]
Sven Eckelmann [Tue, 7 Apr 2026 07:14:25 +0000 (09:14 +0200)]
realtek: dsa: postpone probe due to deferred PHYs
PHY drivers might need access to NVMEM or the filesystem to load
calibration/initialization data. The driver will then return -EPROBE_DEFER
to signal to the device core that the probe should be retried multiple
times again in the 10s driver_deferred_probe_timeout.
But when the switch driver calls dsa_register_switch(), it needs to connect
the PHYs directly. As result, all PHYs without an driver will automatically
get the default driver (either `genphy_c45_driver` or `genphy_driver`)
assigned and initialized. But for PHYs with the additional initialization
data from NVMEM/fs, this will usually result in not working PHYs.
Since there are Realtek based boards with RTL826x PHYs and the new driver
loads the initialization/patch values from rootfs, it is necessary to check
in the beginning of the probe function whether the PHYs are ready and the
probing can continue.
If some driver is still without driver after the deferred probe period
ended, the loading will just continue and the generic PHY drivers will
still be used.
Closes: #22811 Co-authored-by: Jonas Jelonek <jelonek.jonas@gmail.com> Co-authored-by: Markus Stockhausen <markus.stockhausen@gmx.de> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/23075 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Wed, 22 Apr 2026 07:39:58 +0000 (07:39 +0000)]
realtek: pcs: rtl93xx: add shared MAC mode wrapper
RTL930x and RTL931x share a set of extras around MAC mode writes:
- a post-write delay (kept for consistency with the original RTL930x
behaviour; harmless on RTL931x)
- the force-mode bit (RTL931x only, nullable field)
Add rtpcs_93xx_sds_set_mac_mode() as a shared wrapper around the
generic rtpcs_sds_set_mac_mode() that applies each of these extras
unconditionally; the nullable field makes the force-bit write a no-op
on RTL930x.
Route the three RTL93xx call sites (the 930x and 931x set_mode
dispatchers, and 931x set_ip_mode's OFF transition) through the
wrapper, removing the duplicated force-bit handling from each.
The USXGMII submode write stays out of the wrapper and is called
explicitly from the 930x dispatcher via rtpcs_93xx_sds_apply_usxgmii_submode().
Keeping submode as a separate step leaves room for RTL931x to apply it
from its IP-mode path once the submode register is wired up, without
retrofitting a MAC-mode wrapper with side effects.
Jonas Jelonek [Mon, 20 Apr 2026 20:26:12 +0000 (20:26 +0000)]
realtek: pcs: rtl931x: migrate MAC mode setting to regmap_field
RTL931x uses a regular 8-bit-per-SerDes layout in SERDES_MODE_CTRL, so
the reg_field can be computed in the probe hook with simple arithmetic.
The 8-bit-per-SerDes field is split into a 7-bit mac_mode (bits 0..6)
and a 1-bit mac_mode_force (bit 7), each written independently via its
own regmap_field. The mac_mode is widened to 7 bits (rather than the
5 bits strictly needed for the mode value) so MAC mode writes also
clear bit 5 (FEC enable) and bit 6 (10G speedup), matching the original
behaviour where the full 8-bit mask cleared these bits on every mode
change. FEC and speedup are mode-dependent and not yet programmed by
the driver; keeping them cleared leaves headroom for future support
without changing the effective register value.
rtpcs_931x_sds_reset() is updated to save and restore both fields
across the off/on cycle, preserving the original force-bit handling.
rtpcs_931x_sds_set_mode() uses the generic rtpcs_sds_set_mac_mode() and
sets the force bit explicitly; the same sequence also appears in
rtpcs_931x_sds_set_ip_mode()'s OFF transition. Both are folded into
the shared RTL93xx wrapper in a later commit.
Jonas Jelonek [Mon, 20 Apr 2026 20:15:46 +0000 (20:15 +0000)]
realtek: pcs: rtl930x: migrate MAC mode setting to regmap_field
RTL930x packs 5-bit mode fields across four registers at irregular
positions. Express this as a static reg_field table indexed by SerDes
ID; the probe hook allocates the corresponding regmap_field. The
USXGMII submode register follows the same pattern with its own
reg_field table, allocated only for 10G-capable SerDes (id 2..9).
The generic rtpcs_sds_set_mac_mode() replaces the old
__rtpcs_930x_sds_set_mac_mode() helper. The previous behaviour of
writing OFF before the target mode is intentionally dropped — it was
RTL930x-specific and not required by the hardware.
The variant-level rtpcs_930x_sds_set_mode() is kept as a pure dispatch
between the IP mode path (set_ip_mode) and the MAC mode path. The
USXGMII submode write is factored into rtpcs_93xx_sds_apply_usxgmii_submode(),
which derives the submode value from hw_mode and no-ops on SerDes
without the submode register.
The __rtpcs_930x_sds_get_mac_mode() and __rtpcs_930x_sds_get_usxgmii_submode()
helpers are dropped. They were __always_unused and depended on the
removed parallel arrays. A future get_mode path will be added if a
caller needs it, likely mirroring the setter's wrapper shape.
Jonas Jelonek [Mon, 20 Apr 2026 19:43:05 +0000 (19:43 +0000)]
realtek: pcs: rtl839x: migrate MAC mode setting to regmap_field
RTL839x packs the SerDes MAC mode in MAC_SERDES_IF_CTRL with a regular
per-SerDes layout, so the regmap_field can be computed directly in the
probe hook rather than declared as a static table.
Mode values (currently only OFF and QSGMII) move into a static
rtpcs_839x_sds_hw_mode_vals[] table. Values for 100BASEX, 1000BASEX
and SGMII from the vendor SDK are kept as comments for future
reference — they are not yet exercised here.
With no variant-specific extras (no force bit, no companion register,
no submode), rtpcs_839x_sds_set_mode() is removed; setup_serdes calls
the generic rtpcs_sds_set_mac_mode() directly.
Jonas Jelonek [Mon, 20 Apr 2026 19:35:13 +0000 (19:35 +0000)]
realtek: pcs: rtl838x: migrate MAC mode setting to regmap_field
Replace rtpcs_838x_sds_set_mode()'s inline shift/mask arithmetic with
a regmap_field computed and allocated at probe time. The field layout
is regular (5-bit per SerDes, reverse-packed in SDS_MODE_SEL), so the
position can be derived arithmetically from the SerDes ID rather than
declared in a table.
The function keeps its wrapper role because SerDes 4 and 5 have a
second companion register (INT_MODE_CTRL) with its own per-mode value
encoding. Since RTL838x is the only variant with this quirk and the
register is written from only one call site, it is kept inline rather
than abstracted into its own config table.
Jonas Jelonek [Mon, 20 Apr 2026 19:20:49 +0000 (19:20 +0000)]
realtek: pcs: add regmap-based MAC mode infrastructure
All four Realtek PCS variants (RTL838x, RTL839x, RTL930x, RTL931x)
configure the SerDes MAC mode by writing a register field whose layout
varies per variant — different base registers, different bit positions,
and in some cases per-SerDes packing that isn't arithmetically regular.
Add the common infrastructure to express this uniformly:
- per-SerDes regmap_field pointers in a new 'swcore_regs' anonymous
struct on rtpcs_serdes: mac_mode, mac_mode_force (931x only, nullable)
and usxgmii_submode (930x only, nullable).
- a per-variant mode-value table pointer (sds_hw_mode_vals) on
rtpcs_config, keyed by enum rtpcs_sds_mode. Values are s16 with -1 as
the "unsupported" sentinel — u8 with 0 would collide with RTL839x's
OFF value (0x0).
- a generic rtpcs_sds_set_mac_mode() that looks up the value for the
requested mode and writes it via the regmap_field.
Variant-specific extras (post-write delay, force bit, companion register
writes, USXGMII submode handling) will be added in per-variant wrappers
in the following commits.
Pawel Dembicki [Sat, 28 Mar 2026 22:39:16 +0000 (23:39 +0100)]
kernel/kirkwood: 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
Daniel Golle [Mon, 27 Apr 2026 00:46:57 +0000 (01:46 +0100)]
generic: 6.18: fix MediaTek USXGMII driver
LINK_INBAND_ENABLE isn't valid for 5GBase-R/10GBase-R modes which
by definition don't support any in-band an. Correctly report
LINK_INBAND_DISABLE to fix 10G fiber SFP modules no longer working.
While at it also get rid of downstream pn-swap properties in favor
of using the upstream schema.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Besides converting some functions to regmap do some minor
refactoring for rteth_931x_init_mac().
- Use dev_err() instead of classic print functions
- Harmonize ALE_INIT error handling. ALE_INIT_2 has the same
logic as the other registers. The reset is finished as soon
as the register is completely zero.
- From testing 100ms poll timeout seems to be sufficient
Jörg Seitz [Sun, 24 Aug 2025 04:51:11 +0000 (06:51 +0200)]
mediatek: filogic: Add new Router model ZBT-Z8106AX-S
Device support for zbt-z8106ax-s
Specifications:
SoC: MediaTek MT7981B
RAM: 256MiB
Flash: Winbond SPI-NAND 128 MiB
Switch: 1 WAN, 4 LAN (Gigabit) MediaTek MT7531
Buttons: Reset
Power: DC 12V 1A
WiFi: MT7981B 2.4Ghz & 5Ghz
USB 3
M2 slot to hold LTE modem
1 nano SIM slot (user controllable)
Hardware watchdog (confirmed to work)
Router comes in a plastic tower with all antennas internal.
- 4 antennas for LTE 4G/5G communication
- 2 antennas for Wifi 2.4 GHz
- 2 antennas for Wifi 5 GHz
Led Layout:
Power (green, user controllable, default set to OpenWrt Status)
Mobile (green, user controllable)
WLAN 2.4G (green, user controllable)
WLAN 5G (green, user controllable)
WAN (amber, user controllable, set to show eth1)
LAN1 (amber, hardware controlled)
LAN2 (amber, hardware controlled)
LAN3 (amber, hardware controlled)
LAN4 (amber, hardware controlled)
- Prepare your connecting computer to use a static IP in
network 192.168.1.0/24 like
a) 192.168.1.10 netmask 255.255.255.0 (legacy notation)
b) 192.168.1.10/24 (CIDR notation)
- Power down the router and hold in the Reset button.
- While holding in the button power up the router again.
- Hold the button in for 10 seconds and then release.
- Use your browser to go to 192.168.1.1
- If you see a GUI allowing for flashing firmware then you got the right spot.
- Upload the **Factory** image file.
Note: U-Boot GUI it can be used to recover from an incorrect firmware flash.
B. Through OpenWrt Dashboard:
If your router comes with OpenWrt preinstalled (modified by vendor),
you can easily upgrade by going to the dashboard (192.168.1.1) and
then navigate to "System" -> "Backup/Flash firmware"
Flash OpenWRT firmware.
Important: Take care to deselect (untick) option
"keep settings". Settings done by vendor are incompatible with
versions 24.10 or 25.12.
Device features a GPIO controlled hardware watchdog.
Verfied by removing procd controlled watchdog and
seeing device rebooting.
---
Notes:
The zbt-z8106ax-s could be ordered from vendor with a variety of modems.
Mine came with a 4G LTE modem Quectel EC200A.
Quectel firmware was at EC200AEUHAR01A30M16.
Choices for ordering with 5G LTE were available.
Modem communication is set to ethernet control mode (ECM) by vendor.
Package modemmanager works fine with Quectel EC200A.
You may also decide to use FUjR/Qmodem github repository
to have it manage LTE modem.
Please take note that internal switch port named lan5 isn't
wired to LTE modem in model S as opposed to model T.
Just removing lan5 from DTS did cause unwanted reboots whenever
a cable is plugged into LAN ports 1-4. Disabling port lan5
in DTS however works fine. No unwanted reboots due to
plug/unplug cable into any lan or wan port.
Flash instructions:
1. Power on the device with 'reset' key pressed for 5s
2. Set static IP on your PC:
IP 192.168.1.10/24, GW 192.168.1.1
3. Visit http://192.168.1.1 and upload sysupgrade.bin
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.
projects / thirdparty / openwrt.git / log
