EDMA maps RX fill buffers with DMA_TO_DEVICE but unmaps them with DMA_FROM_DEVICE. Use DMA_FROM_DEVICE consistently, release mappings left on RX rings during teardown, and flush ring-disable writes before descriptor cleanup.
Signed-off-by: krava <igor.kravchenko05@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24218
Signed-off-by: Robert Marko <robimarko@gmail.com>
Kernel modules from the packages feed differ between builds on 6.18,
e.g. kmod-v4l2loopback, kmod-jool-netfilter, kmod-pf-ring and
kmod-usb-serial-dmx_usb_module:
-/builder/shared-workdir/build/build_dir/.../linux-6.18.52/include/linux/ucopysize.h
+/tmp/rebuilderd-openwrt.Xebb8P/src/build_dir/.../linux-6.18.52/include/linux/ucopysize.h
These packages call make -C $(LINUX_DIR) M=... without
KERNEL_MAKE_FLAGS, so they get none of the OpenWrt prefix maps. With
6.12 that did not matter, since srctree stayed "." and the kernel
headers were included by a relative path. Since 6.13 srctree holds the
absolute path of the kernel tree for external modules, while kbuild
only maps srcroot, the module directory.
Add a pending patch that maps the kernel tree for external modules too.
It is added before the map of srcroot and before KCFLAGS, and GCC uses
the last matching map, so modules built through KERNEL_MAKE_FLAGS keep
their current output.
Link: https://github.com/openwrt/openwrt/pull/25356
Signed-off-by: Paul Spooren <mail@aparcar.org>
Add upstream patch marking the 'gpll0_main' clock as critical on
IPQ5018 (gcc-ipq5018 driver), backported from upstream commit
33f9cb56cc28 ("clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as
critical").
During boot the APCS core clock feeding the CPUs can use GPLL0 as
its parent. On some boards (e.g. TP-Link Archer AX55 v1 using the
in-tree DTS since v6.18), the ipq-cmn-pll driver's pm_runtime_put()
call in its probe function asynchronously disables
'gcc_cmn_blk_ahb_clk', which in turn disables 'gpll0_main' as well,
hanging the system until the hardware watchdog restarts the board.
Marking gpll0_main as CLK_IS_CRITICAL fixes the underlying issue
directly in the GCC driver, making the previous workaround in
0191-clk-qcom-ipq-cmn-pll-keep-the-CMN-block-bus-clocks-enabled.patch
unnecessary. Drop that patch, as it addressed the same symptom by
keeping the CMN PLL block's bus clocks permanently enabled via a
devres-managed runtime PM reference instead of fixing the actual
critical clock.
Refresh the context in
0721-clk-gcc-ipq5018-remove-the-unsupported-clk-combinati.patch and
0723-clk-qcom-gcc-ipq5018-fix-uniphy-soft-reset-issue.patch, whose
hunks shifted by 9 lines due to the newly inserted patch.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/25386
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add thermal zone for the Wi-Fi chip using the same trip levels and cooling maps as the CPU. The
kernel thermal governor will act on whichever temperature is the highest. There is only a single
heatsink and fan to cover both the SoC and Wi-Fi chip, so tracking both CPU and Wi-Fi temperatures
ensures that neither chip will overheat from low fan speed.
The trip levels are spaced 1.25C apart with double that (2.5C) for the hysteresis, with 5C
hysteresis for the lowest trip level (65C) because it is preferable for the fan to run for longer at
low speed than to stop and start repeatedly.
In the absence of continuous proportional feedback control, tightly grouping the trip levels and
cooling maps minimises the frequency and amplitude of temperature and fan speed oscillations.
The cooling states are set to increments of 5 (out of 255) from 12% to 61% and then increments of 10
from 61% to 100% with kick start speed at 15%. In comparison, the default in mt7981b.dtsi starts at
50% fan speed and leads to constant on/off cycles within a short period of time (every ~2 minutes).
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22936
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add a common dtsi with macros for thermal trip levels and cooling maps that can be included in other
device trees.
The trip levels are spaced 1.25C apart with double that (2.5C) for the hysteresis, with 5C
hysteresis for the lowest trip level (65C) because it is preferable for the fan to run for longer at
low speed than to stop and start repeatedly.
In the absence of continuous proportional feedback control, tightly grouping the trip levels and
cooling maps minimises the frequency and amplitude of temperature and fan speed oscillations.
There are 36 trip levels and the cooling maps start from cooling state 1 (0-index) so cooling-levels
must have at least 37 elements. If greater increments between trip levels/cooling-levels are desired
or needed the cooling-levels can be padded with repeated values.
The THERMAL_TRIPS_COMMON and THERMAL_COOLING_MAPS_COMMON macros take one argument as the prefix to
the trip levels node labels. The prefix must be the same within a thermal zone.
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22936
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
OpenWrt's custom uImage magic patch makes legacy image verification use
params.magic instead of IH_MAGIC.
mkimage initializes this field, while dumpimage leaves it zeroed. This
causes dumpimage to reject valid legacy uImages using the standard
IH_MAGIC with FDT_ERR_BADMAGIC.
Initialize dumpimage's magic to IH_MAGIC so the normal verification path
works by default. Also add -M handling matching mkimage, allowing
dumpimage to verify and extract uImages built with a custom magic.
Tested with the patched U-Boot 2026.07 host tools. Standard-magic images
list and extract correctly, custom-magic images are accepted with the
matching -M value, and are rejected without it or with an incorrect
magic. Extracted payloads were verified byte-for-byte.
Fixes: #25287
Signed-off-by: Massimo Mazzariol <mazzariol.massimo@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25288
Signed-off-by: Robert Marko <robimarko@gmail.com>
The post_config hooks finalize a powered-up SerDes and may calibrate
its receiver. Configure autonegotiation and the BMCR speed first so
finalization runs with the requested PCS state.
This is required for 100BASE-X on RTL930x. Calibrating with the default
1000 Mbps BMCR setting produced symbol errors until BMCR was switched
to 100 Mbps.
Preserve the changed result from set_autoneg across the post_config
callback so pcs_config keeps its existing return semantics.
Tested runtime mode transitions and cold boot on RTL838x, RTL930x and
RTL931x. Links came up and passed traffic in all tested modes with no
regressions observed.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Phylink can only request interface modes advertised by the DSA port.
Expose 100BASE-X when the SoC MAC capabilities include MAC_100 so that
ports backed by a capable PCS can select the newly supported mode.
Keep this independent of MAC_1000FD because the 100 Mbps and 1 Gbps MAC
capabilities are reported separately.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The generic, RTL930x, and RTL931x setup paths now handle 100BASE-X.
Add the RTL93xx hardware mode value and mapping, select the 1G analog
CMU page, and advertise the mode from RTL93xx SerDes instances.
This makes the prepared support available to PCS consumers.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL931x handles 100BASE-X through its 1G fiber digital path, but the
FIB1G link detector must remain disabled at 100 Mbps.
Add 100BASE-X to the fiber setup and symbol-error handling paths. Share
the 1000BASE-X setup while selecting the appropriate FIB1G link-enable
value for each mode. Keep the mode unavailable until the shared
RTL93xx support is enabled.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL930x uses the IP-driven mode setup for Base-X links and the 1G
analog configuration for SGMII and 1000BASE-X.
Route 100BASE-X through the same IP-driven and 1G analog setup paths.
Keep the mode unavailable until all RTL93xx support is in place.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
100BASE-X uses a direct SerDes attachment and the same 1G-class PLL
configuration as 1000BASE-X on the supported hardware.
Teach the common attachment and PLL selectors about the mode. This is
preparation only; no additional SerDes advertises support yet.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
100BASE-X does not use in-band autonegotiation and requires BMCR to
select 100 Mbps. Extend the generic autonegotiation helper to always
disable AN for this mode and then program BMCR_SPEED100.
This ordering is required on RTL93xx, which ignores speed-selection
updates while BMCR_ANENABLE is set.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL93xx ignores BMCR speed-selection updates while BMCR_ANENABLE is
set. The RTL931x mode setup therefore cannot reliably select 1000 Mbps
for forced 1000BASE-X before generic autonegotiation handling runs.
Move forced 1000BASE-X speed selection into the generic helper and
perform it after disabling autonegotiation. This also removes the
ineffective RTL931x-specific write.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Some of these GPIOs are shared between interfaces. Use a regulator to be
able to share them. Enable Kconfig options so that they work.
Backport one patch upstream so the patch applies. Rename another to
clarify it's in 7.2.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25296
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Use the realtek-pse-mcu kernel driver instead of realtek-poe. The MCU
is a Nuvoton M05xx using the gen1 protocol over UART at 19200 baud.
realtek-poe turns off the MCU's port mapping at startup, which reversed
the PoE port numbering and the front-panel PoE LEDs. The kernel driver
leaves the mapping alone, so both now match the front panel. The MCU
keeps this state across a warm reboot, so a unit sysupgraded from a
realtek-poe image stays reversed until its first power cycle.
Tested on a GS110TPP v1: the driver probes the MCU and its BCM59121,
and a PoE device on lan1 is powered.
Signed-off-by: Kel Modderman <kelvmod@gmail.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/25298
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
CompileBPF calls clang with -g but without any prefix map. Stripping debug info
keeps .BTF and .BTF.ext, since libbpf needs them, and their line info carries
the absolute path of each source file. This makes BPF objects like qosify-bpf.o
depend on the build directory and breaks reproducibility:
-/builder/shared-workdir/build/build_dir/.../qosify-bpf.c
+/tmp/rebuilderd-openwrt.juCsuQ/src/build_dir/.../qosify-bpf.c
IREMAP_CFLAGS is not enough here: without CONFIG_REPRODUCIBLE_DEBUG_INFO it
only sets -fmacro-prefix-map, which leaves the line info alone, and it is empty
for external toolchains, which have no say over the host clang. Unlike regular
debug info, BTF ships with the package, so always pass -ffile-prefix-map for
the build and staging directories.
Add an fremap helper next to iremap for that, and let IREMAP_STAGING_DIR and
CompileBPF share the map of the staging directory, so they cannot drift apart.
Link: https://github.com/openwrt/openwrt/pull/25359
Signed-off-by: Paul Spooren <mail@aparcar.org>
The x86 and armsr targets declare the vdi, vmdk and vhdx features, but
VDI_IMAGES, VMDK_IMAGES and VHDX_IMAGES depend on a hardcoded target
list instead, so the features select nothing and a target opting in has
to edit config/Config-images.in.
Give them USES_VDI, USES_VMDK and USES_VHDX in the same shape as the
other image formats and depend on those. The set of targets offering
each format is unchanged.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The atm feature has no entry in target_config_features(), so it selects
no symbol, and nothing else reads the feature list beyond the broken and
source-only filters. It has never gated anything. The kmod-ltq-atm-*
packages are unrelated name matches, pulled in through DEFAULT_PACKAGES.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
"\s" is not an escape sequence in a Perl double-quoted string, so the
pwm feature emits its select statement without the leading tab that
every other feature gets. Kconfig accepts the unindented line, but the
generated target/Config.in is inconsistent.
Fixes: f6fbc39706 ("build: define PWM_SUPPORT arch feature flag")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The ubus notification for link measurements was added by replacing the
call to hostapd_handle_link_mesr_report() instead of adding to it, so
upstream's handler lost its only caller and is compiled out as dead
code, which the build shows as:
src/ap/rrm.c:354:13: warning: 'hostapd_handle_link_mesr_report'
defined but not used [-Wunused-function]
As a result nothing clears hapd->link_mesr_req_active or cancels
hostapd_link_mesr_rep_timeout_handler() when a report arrives, so a
REQ_LINK_MEASUREMENT issued over the control interface always ends in a
timeout even though the report was received, and the LINK-MSR-RESP-RX
event carrying the report is never emitted.
Call both handlers, which is how the ubus hook for beacon reports a few
lines above is wired up too.
Fixes: f6445cfa1a ("hostapd: add ubus link-measurements notifications")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25242
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
apup_process_beacon() adds the peer with ap_sta_add() and only asks for
an AID with hostapd_get_aid() further down. When that fails the function
returns without undoing anything, leaving the station in hapd->sta_list
with WLAN_STA_AUTH set but with no AID, no WLAN_STA_ASSOC and no WDS
interface. The driver entry added by the preceding hostapd_sta_add() and
the hapd->num_sta reference are leaked as well.
The leftover entry is then found by the ap_get_sta() check at the top of
the function, so every later beacon from that BSSID returns early and
the peer can never be set up again until hostapd is restarted.
Release the half-initialised station with ap_free_sta(), which removes
the driver entry, cancels the inactivity timer registered by
ap_sta_add(), unlinks it from the list and drops the counters.
Fixes: e80520197c ("hostapd: Add support for APuP")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25242
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
apup_process_beacon() dereferenced the return value of ap_sta_add()
without checking it. ap_sta_add() returns NULL when the station table is
full, when the allocation fails or when accounting_sta_get_id() fails,
so the following read of sta_ret->aid dereferences NULL.
The station table filling up is remotely triggerable. Beacons reach
handle_beacon() on every softmac driver, because hostapd subscribes to
them per wiphy with NL80211_CMD_REGISTER_BEACONS when it starts the AP.
An adjacent station can therefore beacon the target's SSID from
successive spoofed BSSIDs, each of which is added as an APuP peer, until
max_num_sta is reached and hostapd crashes.
CONFIG_APUP=y is set unconditionally in DRIVER_MAKEOPTS, so the code is
compiled into every wpad variant, but the call is gated on
hapd->conf->apup at runtime and wifi-scripts defaults apup to 0. Only
configurations that opt into APuP are affected.
Reported-by: JuliusBairaktaris
Fixes: e80520197c ("hostapd: Add support for APuP")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25242
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This appears to reduce the CPU temp by at least a few degrees C on
Linksys EA4500, which is notorious for its thermal challenges.
Tested only on EA4500 by running without issues for a few weeks under a
light workload.
Signed-off-by: Will Mortensen <willmo@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25276
Signed-off-by: Robert Marko <robimarko@gmail.com>
Armada 38x uses Cortex-A9 r4p1, but the current kernel config selects
erratum 720789, which was fixed in r2p0, and omits some errata that
still affect r4p1. Fix the config.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25297
Signed-off-by: Robert Marko <robimarko@gmail.com>
The WR3000S has a GPIO LED behind its front-panel "Internet" lamp
(white:wan-online, &pio 11), but no board.d entry, so no trigger is ever
set and the lamp stays dark. Give it the same netdev trigger the WR3000H
and WR3000P already use for their white:wan-online LED: follow the link
state of the wan port. As on those boards, "link" means the wan port has
carrier, not that connectivity works.
The panel's WAN and LAN1-4 lamps are not GPIO LEDs and are not registered
as Linux LEDs at all; they light on link in hardware, so board.d cannot
address them and they are untouched here. The -ubootmod variant includes
the same mt7981b-cudy-wr3000s-v1.dtsi, and so the identical LED, and is
listed alongside.
Tested on a WR3000S v1 (OEM layout), on an image built from main at
6727587d24 plus this commit: after a config-wipe sysupgrade the board.d
entry is applied automatically (board.json -> system.led_internet), the
lamp lights while the WAN port has link, and it goes dark when it loses
link. Only the OEM-layout variant was flashed.
Signed-off-by: Ivan Rainbolt <ivan@github.ivanthegeek.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/25335
Signed-off-by: Robert Marko <robimarko@gmail.com>
The driver doesn't really care about the address in dts, but might as
well fix it anyway.
0 is just wrong.
1f is the address for the builtin FE switch, not the external gigabit
switch.
10 is the driver default.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25370
Signed-off-by: Robert Marko <robimarko@gmail.com>
The APEX boot loader embeds the time of the build in its version
banner, which makes the Iomega NAS100D factory image differ between
builds:
-compiled for OpenWrt NAS100D/BE on 2026.Sep.23-04:17:21
+compiled for OpenWrt NAS100D/BE on 2026.Sep.23-11:06:03
APEX sets BUILDDATE with $(shell date) in its top level Makefile. Pass
BUILDDATE on the command line, formatted from SOURCE_DATE_EPOCH in UTC
and the C locale, which overrides it for all sub-makes.
Link: https://github.com/openwrt/openwrt/pull/25354
Signed-off-by: Paul Spooren <mail@aparcar.org>
Since b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") the
fork path snapshots kill_seq in cgroup_css_set_fork() before the
CLONE_INTO_CGROUP target has been resolved, so it always records the
forking task's own cgroup while cgroup_post_fork() reads the target's
and compares the two. Once cgroup.kill has been written to a cgroup,
every child later cloned out of it into another cgroup is SIGKILLed
before it runs a single instruction, for as long as that cgroup exists.
This breaks re-creating an OCI container under procd, whose service
supervisor kills the instance cgroup on exit and leaves it in place: the
container init ujail clones with CLONE_INTO_CGROUP is killed at birth and
the create fails with no diagnostic. The fix is in mainline from v7.3-rc2
and carries Cc: stable, so it is expected to reach 6.18.y with a future
stable release, at which point this patch can be dropped.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Charter Spectrum SBE1V1K fails to boot with the default kernel
load address. The device gets stuck early in the boot process due to
the stock bootloader encountering memory overlap or alignment issues
with the default `0x41000000` address.
Changing `KERNEL_LOADADDR` to `0x42200000` resolves the boot failure
and ensures stable operation.
Why `0x42200000` instead of `0x42000000`?
While testing showed that `0x42000000` also boots successfully,
`0x42200000` was explicitly chosen for two primary safety reasons:
1. Avoid U-Boot `loadaddr` Overlap: On many QCA/IPQ platforms,
`0x42000000` is commonly used as the default `loadaddr` to fetch
the FIT image into memory. Setting the extraction destination
(`KERNEL_LOADADDR`) to the exact same base address risks in-place
decompression overlaps.
2. Reserved Memory Buffer: The memory range below `0x42000000`
is heavily utilized by TZ, SMEM, and vendor-specific reserved
memory in newer Askey firmwares. Adding a 2MB aligned offset
(`0x200000`) provides a safer buffer against shifting vendor
memory boundaries in future OEM bootloader updates, while still
strictly satisfying the ARM64 2MB alignment requirement.
This fix and the `0x42200000` address have been successfully tested
on actual SBE1V1K hardware by community member motolav.
Link: https://forum.openwrt.org/t/spectrum-sbe1v1k-ipq9574-openwrt-support/245244/262
Tested-by: motolav <https://forum.openwrt.org/u/motolav>
Signed-off-by: Jackie Han <jackie.han@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25344
Signed-off-by: Robert Marko <robimarko@gmail.com>
The driver carried the constants for all three sensors but registered
one zone and read only the bandgap one. Register a zone per sensor and
add two zones to the device tree.
The bandgap sensor stays zone 0 with its trips and cooling map.
#thermal-sensor-cells goes from 0 to 1.
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25147
Signed-off-by: Robert Marko <robimarko@gmail.com>
Two thermal zones reading the shared ADC at once interleave and convert
another sensor's diodes with the wrong constants. On AN7583 the zone
carrying the critical trip crossed 120 C on a chip at 55 C, shutting the
board down.
Serialise the sequence, read the mux selection back instead of caching
it, check it again after sampling and refuse to divide by a zero gain.
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25147
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Quectel EG120K-EA (LTE Cat.12) reports USB ID 2c7c:030b and exposes
its QMI/RMNET function on a vendor-specific ff/ff/ff interface. The same
product ID is already known to the option driver as EM060K, which claims
the serial interfaces, but without a qmi_wwan entry the data interface is
left unbound and no cdc-wdm node appears.
Add the device using QMI_MATCH_FF_FF_FF so the DTR quirk is applied.
Tested on a GL.iNet GL-X2000, where the modem enumerates at SuperSpeed and
now brings up cdc-wdm0 and wwan0. A data session over MEO (268-06) was
verified end to end.
Accepted upstream via netdev/net, so this is carried as a backport and can
be dropped once the kernel is bumped to 7.3 or later. Inserting it ahead of
the MeigLink hack shifts that patch's offsets, so
780-usb-net-MeigLink_modem_support.patch is refreshed as well.
Link: https://patch.msgid.link/20260921093426.2870266-1-gilbertorconde@gmail.com
Signed-off-by: Gilberto Conde <gilbertorconde@gmail.com>
The factory images of the Linksys LGS3xxC switches differ between
builds in the Belkin header:
-00000000: 0780 0001 7917 f807 6ab3 0fe3 0058 2000 ....y...j....X .
+00000000: 0780 0001 2a5a 3f79 6ab3 d0c7 0058 2000 ....*Z?yj....X .
belkin-header.py stores time.time() as the image time, which also
changes the header checksum. Use SOURCE_DATE_EPOCH when it is set, like
linksys-image.sh does for the tarball inside.
Link: https://github.com/openwrt/openwrt/pull/25355
Signed-off-by: Paul Spooren <mail@aparcar.org>
Both 10G ports have a yellow and a green LED driven by the RTL8261CE
rather than by GPIO. Index 2 is yellow, index 3 green. The
index-to-colour mapping was determined empirically by inverting the
polarity bits in VEND2 0xd044 one at a time.
Configure the triggers to match the 1G ports on this board, where green
means gigabit: yellow for 10/100, green from 1000 up, and both together
for 10000. Without this the LEDs come up with no trigger and stay dark,
losing the firmware defaults they had before.
The indices were only verified on an RTL8261CE. Board revisions carrying an
RTL8261N are unaffected for now since that driver has no LED callbacks, but
the mapping should be rechecked there before relying on it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Hardware revisions of this board ship either an RTL8261N, handled by the
out-of-tree RTL826x driver, or an RTL8261CE, handled by the mainline
driver. The two need different firmware and the revision is not known at
image build time, so ship both.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The realtek PHY driver requests rtl_nic/rtl8261c.bin for the RTL8261C.
The blob has been in linux-firmware since 2026-05-28 and is present in
the 20260910 tarball already used here, but it is not matched by any of
the r8169-firmware globs, so nothing installs it today.
The RTL8261D handled by the same phy_driver entry needs no firmware, so
this stays a standalone package rather than a kmod-phy-realtek
dependency, which would pull the blob onto every board with any Realtek
PHY.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The RTL8261C/D drive their LEDs through the same register block as the
RTL8221B, with four LEDs instead of three and two more speed bits. Wire
the callbacks to the RTL8261C_CG and RTL8261CE_CG entries so the 10G
ports of the Gemtek W1700K can be driven from the netdev trigger instead
of coming up dark.
Submitted upstream in the same series as the SerDes lane polarity patch.
Apply it ahead of the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch as well, so it too
can be carried exactly as submitted. 742's realtek_drvs[] hunk is rebased
on top of it, which only moves its leading context.
Refresh out-of-tree patches in realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The Gemtek W1700K routes the USXGMII lanes between the AN7581 and its
RTL8261CE inverted and describes that in the device tree, but nothing in
the RTL8261C/D driver reads tx-polarity/rx-polarity and the Airoha PCS
has no polarity handling of its own. The copper side negotiates normally
while the SerDes never trains and the netdev stays NO-CARRIER.
Add a read and a read-modify-write helper for the VEND1 SerDes command
window and program the lane polarity from rtl8261x_config_init().
Submitted upstream as part of a series documenting the RTL8261C/D device
tree bindings and adding SerDes lane polarity and LED support.
Apply it ahead of the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch so it can be carried
exactly as submitted. 742 drops its own select PHY_COMMON_PROPS and its
phy-common-props.h include, as both come from here now. Once accepted
upstream this patch only moves to backports, so they stay dropped.
Refresh out-of-tree patches in realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backport support for the Realtek RTL8261CE_CG (PHY ID 0x001cc899),
merged for v7.4. It shares the sub-PHY-ID and the firmware with the
RTL8261C_CG.
ca44c21fc117 ("net: phy: realtek: add support for RTL8261CE_CG")
Parts reporting this PHY ID fall through to the generic Clause 45
driver. Both 10G ports of the Gemtek W1700K carry one and never come up.
The patch applies before the out-of-tree
742-net-phy-realtek-add-5G-and-10G-PHY-support.patch, which is where the
RTL_8261N/RTL_8264/RTL_8264B context around the new define comes from, so
742 gains the RTL_8261CE_CG define as context.
Refresh various out-of-tree patches in generic and realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Backport the upstream series adding support for the Realtek RTL8261C_CG
(PHY ID 0x001cc898) and RTL8261D 10Gbps PHYs, merged for v7.3 as
"add-support-for-rtl8261c-d".
Both parts share the PHY ID and are told apart by a sub-PHY-ID read from
the vendor extension page (0x00 for the RTL8261C, 0x81 for the RTL8261D).
The RTL8261C loads rtl_nic/rtl8261c.bin, the RTL8261D needs no firmware.
Two Clause 45 helpers the driver depends on are backported along with it.
3b63c19e64f8 ("net: phy: c45: add genphy_c45_pma_soft_reset()")
d7722c03089e ("net: phy: c45: add setup and read master/slave helpers")
b772b5ae4537 ("net: phy: realtek: add support for RTL8261C_CG")
a04171a1cf32 ("net: phy: realtek: load firmware for RTL8261C_CG")
f0667918d5fc ("net: phy: realtek: add support for RTL8261D")
Refresh various out-of-tree patches in generic and realtek target.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Simon Polack <spolack+git@mailbox.org>
Link: https://github.com/openwrt/openwrt/pull/25092
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add support for RTL9302B-based Ubiquiti UniFi USW Pro Max 24 PoE switch
with 16x GbE and 8x 2.5G RJ45 ports, 2x SFP+, and a front display.
Hardware
========
- RTL9302B switch SoC
- 512 MiB RAM
- 32 MiB SPI-NOR flash
- 16x 100M/1G RJ45 ports via 2x RTL8218E
- 8x 100M/1G/2.5G RJ45 ports via 2x RTL8224
- PoE:
- 400W total budget
- 8x 802.3at, 32W per port (ports 1-8)
- 16x 802.3bt, 60W per port (ports 9-24)
- 2x SFP+ ports
- Buttons: 1x Reset
- LEDs: RGBW LED per port (Etherlighting)
- Front touch display via USB ACM (see below)
- Console: TTL 3.3V, 115200 8N1 (internal pin header close to SoC;
layout front to back: VCC RX TX GND)
- Etherlighting feature (lighting patterns and color control)
- Vendor firmware: U-Boot + LEDE-based Ubiquiti OS
MAC address
===========
Single MAC address in EEPROM partition, applied to all ports.
Front touch display
===================
The unit has a touch-capable front display, driven by a dedicated
STM32-based MCU. Unlike other Ubiquiti switches where the MCU is
connected to the SoC via UART directly, here it is exposed as a USB
CDC-ACM serial device through an on-board Genesys Logic GL850G USB hub.
The MCU runs Ubiquiti's LCM firmware and exposes a high-level JSON
protocol (page selection, button-press events, etc.); arbitrary
pixel-level control is not possible without replacing the MCU firmware.
Display support therefore depends on both USB host support and a driver
for the LCM protocol, neither of which is currently available.
Known issues
============
- Etherlighting not controllable, driver WIP. Port LEDs for link work
though. By default, the controller keeps the LEDs in a breathing
state, gated by the link state delivered by the Realtek SoC.
Disclaimer
==========
Stock firmware uses a dual-bank layout (kernel0/kernel1, ~15 MiB each).
OpenWrt replaces both banks with a single contiguous firmware partition.
Flashing OpenWrt writes or invalidates both stock kernel slots; U-Boot
remains intact and can be used for recovery.
Installation
============
1. Enable SSH on the stock UniFi OS and log in with user account.
2. Copy the OpenWrt sysupgrade image to /tmp on the switch (e.g. via
scp).
3. Adjust IMG below to point at the copied file, then run the block as a
whole. It verifies the expected stock partition layout and image size,
writes kernel0, splits into kernel1 if the image is larger than that
slot (otherwise invalidates kernel1 so U-Boot cannot pick a stale
bank), and reboots:
set -e
IMG=/tmp/openwrt-realtek-rtl930x-ubnt_usw-pro-max-24-poe-squashfs-sysupgrade.bin
K0_SIZE=$((0xf10000))
K0_BLOCKS=$((K0_SIZE / 0x10000))
grep -q '^mtd2: 00f10000 00010000 "kernel0"$' /proc/mtd
grep -q '^mtd3: 00f20000 00010000 "kernel1"$' /proc/mtd
IMG_SIZE=$(wc -c < "$IMG")
[ "$IMG_SIZE" -gt 0 ]
[ "$IMG_SIZE" -le $((0x1e30000)) ]
dd if="$IMG" of=/dev/mtdblock2 bs=64k count=$K0_BLOCKS conv=fsync
if [ "$IMG_SIZE" -gt "$K0_SIZE" ]; then
dd if="$IMG" of=/dev/mtdblock3 bs=64k skip=$K0_BLOCKS conv=fsync
else
dd if=/dev/zero of=/dev/mtdblock3 bs=64k count=1 conv=fsync
fi
sync
reboot
The switch comes up in OpenWrt after reboot.
4. It is recommended to modify the bootcmd to speed up the boot and
prevent any issues due to the dual-boot selection. Since U-Boot by
default uses bootubnt which does a lot of (unneeded) RTK
initialization, quite some time passes until Linux is started.
Additionally, the U-Boot logic fiddles with some bits on flash which
causes JFFS2 errors in OpenWrt. While this doesn't seem to cause
issues yet, be defensive and set the bootcmd from OpenWrt with:
fw_setenv bootcmd 'bootm 0xb40b0000'
fw_printenv bootcmd
This directly boots the uImage from flash, without doing all the
initialization. OpenWrt is able to bootstrap the networking
completely on its own.
It does not matter which bank stock booted from when the dd block
runs: both banks are touched in the same pass (kernel0 written, kernel1
either written or invalidated). With kernel1 invalidated, U-Boot's
internal fallback kicks in and permanently switches to kernel0 on the
next boot, so the device stays on OpenWrt as long as kernel0 is
bootable.
Recovery
========
Since the installation procedure invalidates or partially overwrites
the second bank, recovery requires serial console access (see Hardware
above for pinout).
1. Interrupt U-Boot autoboot by spamming a key during early boot to
drop into the U-Boot prompt.
2. Bring up networking:
rtk network on
3. Transfer an OpenWrt initramfs image via TFTP and boot it:
tftpboot 0x82000000 <server>:<initramfs.bin>
bootm 0x82000000
4. From the running initramfs OpenWrt, do a sysupgrade to reflash
OpenWrt or whatever you want to recover. There is no need for the
complicated procedure from installation since OpenWrt sees the
firmware partition already as a whole.
Return to stock firmware
========================
There is no fully-supported revert path. The stock firmware blob is a
Ubiquiti UBNT archive (header + parts, see firmware-utils' fw.h) that
embeds a u-boot and a kernel0 uImage payload; only the latter is
relevant when writing back to the kernel partitions.
The snippet below extracts the kernel0 uImage from such a blob by
locating the uImage magic and using the size carried in the uImage
header itself, without parsing any UBNT framing. It is provided as a
best-effort starting point; verify the result before flashing,
otherwise you're on your own:
BLOB=<firmware.bin>
OFF=$(grep -aboF $'\x27\x05\x19\x56' "$BLOB" | head -1 | cut -d: -f1)
SIZE=$(( $(dd if="$BLOB" bs=1 skip=$((OFF + 12)) count=4 2>/dev/null \
| hexdump -e '1/4 "%u"') + 64 ))
dd if="$BLOB" of=kernel0.uImage bs=1 skip="$OFF" count="$SIZE"
Once you have a clean uImage, boot an OpenWrt initramfs as described in
Recovery, copy kernel0.uImage to /tmp, and run:
set -e
[ "$(wc -c < /tmp/kernel0.uImage)" -le $((0xf10000)) ] || exit 1
mtd write /tmp/kernel0.uImage firmware
fw_setenv bootcmd bootubnt
fw_printenv bootcmd
reboot
After rebooting, Ubiquiti's firmware should boot.
Or, if you made backups of the flash before installation, just write
the backup back to flash.
Link: https://github.com/openwrt/openwrt/pull/25280
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The RTL8218E exposes XSGMII as one logical SerDes, but its eight
MAC-side channels are represented by two groups of four. The initial
setup disables autonegotiation only for the first group on page 0x400,
leaving the second group on page 0x500 in autonegotiation mode.
Consequently, the first four package ports pass traffic while the
remaining four establish copper link but do not pass packets. Disable
XSGMII autonegotiation for the second group as well by forcing
register 0x500.12[9:8] to 01.
This changes 0x500.12 from 0x70d0 to 0x71d0 and brings
0x507.15[7:4] from 0 to 0xf on hardware, after which all eight ports
pass traffic.
Fixes: 2db820be865f ("realtek: phy: fix RTL8218E XSGMII initialization")
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25364
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Now that 6.18 is the only supported kernel version for bcm53xx,
remove the 6.12 kernel configs (config-6.12 and per-subtarget
config-6.12 files) and the entire patches-6.12 patch stack, as they
are no longer used.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25307
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
krava
Robert Marko
Paul Spooren
Mieczyslaw Nalewaj
Ryan Leung
Massimo Mazzariol
Jonas Jelonek
Rosen Penev
Kel ModdermanandClaude Opus 5.5
Daniel Golle
Hauke Mehrtens
Will Mortensen
Qingfang Deng
Ivan RainboltandClaude Opus 5
Shiji Yang
Jackie Han
Vitaliy Sochnev
Gilberto Conde
Simon Polack