OrbisAI Security [Fri, 15 May 2026 01:25:24 +0000 (06:55 +0530)]
ixp4xx-microcode: use snprintf in IxNpeMicrocode.h
Replace sprintf() calls with snprintf() to bound writes into the
fixed-size filename[] and slnk[] stack buffers. While the current
inputs are hash-pinned firmware images, snprintf provides defense
in depth against buffer overflows if the format string output ever
exceeds buffer capacity.
Ryan Leung [Wed, 6 May 2026 11:31:01 +0000 (21:31 +1000)]
scripts: feeds: don't refresh .config upon update
Feeds update does not make updated packages available to compile; they must be installed.
Despite this, update refreshes the .config, deleting selections in the .config which have not been
installed yet. The deleted selections are not restored with `./scripts/feeds install` nor with
`make defconfig` because these steps cannot conjure up already deleted selections.
Change update to not modify the .config and leave it to `./scripts/feeds install -d <y|m|n>` or
`make defconfig` or other *config options.
Joshua Covington [Fri, 26 Jun 2026 12:22:45 +0000 (12:22 +0000)]
kernel: add Kconfig options for ARM64_BRBE and THP enhancements on 6.18
Introduce new kernel configuration options for memory management
and hardware-profiling features:
- KERNEL_ARM64_BRBE: Enables support for the Branch Record Buffer
Extension (FEAT_BRBE) on ARM64 architectures when perf events are active.
- KERNEL_PERSISTENT_HUGE_ZERO_FOLIO: Allows allocating a PMD-sized
folio for zeroing, optimizing Transparent Hugepage (THP) allocation
performance.
- KERNEL_NO_PAGE_MAPCOUNT: Adds experimental support for bypassing
per-page mapcount tracking to reduce memory accounting overhead under THP.
These options map directly to their respective kernel options and are
applicable on 6.18 and later.
Joshua Covington [Mon, 22 Jun 2026 21:56:35 +0000 (21:56 +0000)]
bcm27xx-gpu-fw: remove dependency for bcm2712
bcm2712 uses a dedicated eeprom chip with closed-source blobs
provided via rpi-eeprom which is part of the bcm27xx-utils.
No need to install the old firmware files on this target.
Joshua Covington [Mon, 22 Jun 2026 21:55:36 +0000 (21:55 +0000)]
bcm27xx: do not install bcm27xx-gpu-fw on bcm2712
bcm2712 uses a dedicated eeprom chip with closed-source blobs
provided via rpi-eeprom which is part of the bcm27xx-utils.
No need to install the old firmware files on this target.
This is triggered by CONFIG_ALL_KMODS=y. The old 32-bit Raspberry Pi
subtargets do not normally select this driver for runtime use, but all-kmods
forces the kmod package to be built anyway. On 32-bit ARM, raw 64-bit
division in a module can cause GCC to emit the ARM EABI helper
__aeabi_uldivmod, which is not available as a kernel module symbol.
The failing reference comes from i2c-designware-master.c, where clock_calc()
uses raw u64 division for SCL timing calculations (introduced with commit 3805d13c3ead21494f7d00aa44f10e3656363d4c in rpi-6.18.y / "i2c: designware:
Support non-standard bus speeds"). That is a kernel-side portability issue,
but these old bcm27xx subtargets do not use DesignWare I2C hardware. They
use the Broadcom I2C controller instead.
The failure is emitted for i2c-designware-core.ko, so guard the hidden core
package itself rather than only guarding the platform or PCI frontend package.
This prevents CONFIG_ALL_KMODS from selecting the failing core module directly
on the affected 32-bit bcm27xx subtargets.
DesignWare I2C is relevant for newer Raspberry Pi 5 / RP1 based systems, so
keep it available for bcm2712.
A similar issue was reported by NixOS for Raspberry Pi ARM builds, where
i2c-designware-core.ko failed with the same unresolved __aeabi_uldivmod symbol.
Their workaround was to disable the DesignWare I2C symbols for older Raspberry
Pi targets that do not need them. Link: https://github.com/NixOS/nixpkgs/issues/464515
Until the underlying ARM32 kernel-side issue is fixed, avoid building
the DesignWare core package on bcm2708, bcm2709 and bcm2710.
Joshua Covington [Mon, 22 Jun 2026 21:52:08 +0000 (21:52 +0000)]
bcm27xx: adapt RP1 and media kernel modules for 6.18
kmod-rp1:
kmod-rp1-mailbox:
RP1 is the I/O controller on the BCM2712 SoC. The RP1 drivers are compiled
directly into the kernel, granting access to peripherals at early boot.
Consequently, separate packages are no longer required for 6.18 on bcm2712.
kmod-rp1-cfe:
Adapt kmod-rp1-cfe packaging for Linux 6.18 kernel changes,
by updating module paths and dependencies for the upstream driver.
kmod-rp1-cfe-downstream:
kmod-rp1-hevc-dec:
Package downstream CFE and HEVC decoder drivers for bcm2712 on 6.18.
kmod-vc4:
Add a conditional dependency on kmod-drm-exec for 6.18 builds
and move DRM helper modules to their corresponding helper kmods.
Joshua Covington [Mon, 22 Jun 2026 21:19:04 +0000 (21:19 +0000)]
bcm27xx: add 6.18 patches from the RPi repo up to 6.18.37
These patches were generated from:
https://github.com/raspberrypi/linux/commits/rpi-6.18.y
Patches were generated from the diff between linux kernel branch linux-6.18.y
and rpi-6.18.y from raspberry pi kernel source:
git format-patch -N linux-6.18.y..rpi-6.18.y (HEAD)
(HEAD -> 9df439fbf76c0cb9f1a9282a7bf44b3405d51690) as of 20260701
"Commit: Merge remote-tracking branch 'stable/linux-6.18.y' into rpi-6.18.y"
Andrew LaMarche [Thu, 29 Jan 2026 00:52:36 +0000 (00:52 +0000)]
mac80211: read calibration variant from device tree
ath10k and ath11k support reading calibration variants from the device
tree to locate the correct Board Description File (BDF). The ath12k-wsi
binding already describes using qcom,calibration-variant but it is not
implemented in the driver.
Many ath12k designs expose all the radios under a single phy, each of
which typically require a separate BDF. Without this, the radios may not
come up or will not be calibrated correctly.
Fix this by parsing the device tree for the generation-agnostic
qcom,calibration-variant. This allows the driver to properly select,
read and apply the correct BDF.
Additionally, the ath12k-wsi binding documentation describes using the
generation-specific qcom,ath12k-calibration-variant binding as well as
the generation-agnostic qcom,calibration-variant binding to load
board-specific calibration data from the device tree. However, the
driver never implemented either of these.
Given that no devices currently supported use
qcom,ath12k-calibration-variant and the previous patch implements
qcom,calibration-variant, drop the generation-specific version from the
binding to prevent future confusion.
wifi-scripts: restore priv_key/priv_key_pwd as config aliases
The shell config generator read the client private key from the UCI
options priv_key / priv_key_pwd (and priv_key2 / priv_key2_pwd for the
inner tunnel). The ucode generator was switched to private_key /
private_key_passwd (matching the wpa_supplicant field names), and LuCI
was updated accordingly, but existing configurations still carry the old
option names.
Such configs silently lose their private key: for an EAP-TLS client this
leaves wpa_supplicant without a client key and authentication fails after
upgrading from 24.10.
The schema already lists priv_key / priv_key_pwd, but as plain strings,
so validate() never migrates them. Declare them (and the missing
priv_key2 / priv_key2_pwd) as aliases of the private_key* options so the
old names keep working.
The supplicant config generator emitted the altsubject_match,
domain_match and domain_suffix_match server certificate constraints
through the plain (unquoted) variable list. As these are UCI arrays,
they were rendered space-separated and without quotes, e.g.
wpa_supplicant parses an unquoted string value as a hex blob, so such a
line fails to parse and the constraint is dropped. wpa_supplicant
expects a single quoted, semicolon-separated string:
Join these lists with semicolons and emit them as quoted strings.
The inner-tunnel (phase 2) constraints subject_match2, altsubject_match2,
domain_match2 and domain_suffix_match2 were not written to the config at
all; emit them as well. Add the matching inner EAP-TLS options ca_cert2,
client_cert2, private_key2 and private_key2_passwd to the schema so they
validate cleanly.
The supplicant config generator emitted the phase2 directive as
phase2="auth=${auth}" for every PEAP/TTLS/FAST configuration. That is
wrong whenever the configured inner method is an EAP method: for
auth='EAP-MSCHAPV2' it produced phase2="auth=EAP-MSCHAPV2", which
wpa_supplicant rejects with:
TLS: Unsupported Phase2 EAP method 'EAP-MSCHAPV2'
breaking WPA-Enterprise clients that use an EAP inner method.
Mirror the shell config generator (hostapd.sh): strip the "EAP-" prefix
and pick the phase2 prefix from the method type, i.e. "autheap=" for a
tunneled EAP method with TTLS and "auth=" for a non-EAP method or a
full "auth=..." spec provided by the user.
Fixes: https://github.com/openwrt/openwrt/issues/24086 Fixes: c92ded2f6e7a ("wifi-scripts: fix EAP STA support in supplicant config generation") Assisted-by: Claude:claude-opus-4-8 Link: https://github.com/openwrt/openwrt/pull/24088 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
wifi-scripts: ucode: add gcmp256 option, default GCMP-256 per WPA3 mode
Commit 1f86f4e471f8 ("wifi-scripts: ucode: simplify wpa_pairwise default
selection") made HE and EHT BSSes default their pairwise cipher to
"GCMP-256 CCMP", and commit 86b9eec8f02b ("wifi-scripts: ucode: add
WPA3-Personal Compatibility Mode") always put GCMP-256 into the RSNE
Override 2 element on EHT compatibility-mode BSSes.
WPA3 Specification v3.5 only makes GCMP-256 mandatory when the BSS enables
EHT or MLO (section 2.5, item 5); for HE and below the WPA3 and Wi-Fi
Enhanced Open Deployment Guide v1.1 lists it as recommended, not required.
Advertising it by default causes interoperability problems: several
clients fail to associate when GCMP-256 is offered as a pairwise cipher
and connect again with CCMP only (Nanoleaf devices, a Motorola/Unisoc
phone, a Linux/iwd laptop).
Add a gcmp256 UCI option and, like sae_ext_key, default it on only where
GCMP-256 is both mandatory and safe: on Compatibility mode (sae-compat)
BSSes running an EHT htmode, which carry it in a separate RSNE Override 2
element that legacy clients ignore. It defaults off for WPA3-Personal
(sae) and Transition (sae-mixed) mode and on non-EHT BSSes. An explicit
'option gcmp256 0/1' overrides the default per BSS.
Both GCMP-256 pairwise defaults now key off config.gcmp256 (and, from the
earlier driver-support change, the phy actually implementing the cipher):
the sae/sae-mixed "GCMP-256 CCMP" pairwise cipher and the sae-compat RSNE
Override 2 element. The 'encryption sae+gcmp256' suffix and the wpa3-192
mode still force GCMP-256 as before.
wifi-scripts: ucode: default the SAE-EXT-KEY AKM per WPA3 mode
Commit a12cec9ea3c8 ("wifi-scripts: ucode: advertise SAE-EXT-KEY AKM
alongside SAE") advertised the SAE-EXT-KEY AKM (00-0F-AC:24, SAE using a
group-dependent hash, aka SAE-GDH) by default on every sae, sae-mixed and
sae-compat BSS.
WPA3 Specification v3.5 only makes this AKM mandatory when the BSS enables
EHT or MLO (section 2.5, item 4); for HE and below it is merely
recommended (sections 2.2 and 2.3). In practice the FT-SAE-EXT-KEY AKM
(SAE-EXT-KEY combined with 802.11r), which gets added automatically once
Fast Transition is enabled, keeps some clients from associating (a Samsung
Galaxy Tab S10 FE) or makes them reboot shortly after connecting (a Poco
X6). Plain SAE-EXT-KEY without FT was seen to work on the same tablet, but
its interoperability is not well tested.
Drop the fixed schema default and pick the default from the auth type in
parse_encryption instead. Only default it on where it is both mandatory
and safe to offer: on Compatibility mode (sae-compat) BSSes running an EHT
htmode, which carry it in a separate RSN Override element that legacy
clients ignore. Keep it off for WPA3-Personal (sae) and Transition
(sae-mixed) mode, where it would sit in the main RSNE that a choking
client cannot ignore, and off on non-EHT BSSes. An explicit
'option sae_ext_key 0/1' still overrides this per BSS.
The SAE-EXT-KEY AKM in the sae-compat RSN Override 2 element now keys off
config.sae_ext_key alone; the extra config.rsn_override_pairwise_2 guard
is dropped, decoupling the AKM from the GCMP-256 pairwise cipher so each
follows its own option.
wifi-scripts: ucode: only advertise GCMP-256 when the driver supports it
The GCMP-256 pairwise cipher was advertised based only on the BSS htmode
(HE/EHT), without checking whether the driver actually implements it. On
phys that do not support GCMP-256 this makes hostapd reject the
configuration and fail to start.
Query the phy's NL80211 cipher suite list in device_capabilities() and
expose a phy_features.cipher_gcmp256 flag, then only offer GCMP-256 when
the driver advertises the GCMP-256 cipher suite (00-0F-AC:9, 0x000fac09),
mirroring how the HT/VHT feature flags are already gated on the reported
phy capabilities. This covers both the sae/sae-mixed "GCMP-256 CCMP"
pairwise default and the GCMP-256 pairwise cipher in the sae-compat RSNE
Override 2 element.
The "GCMP-256 CCMP" default now keys off driver support alone instead of
the htmode; a follow-up commit reintroduces the per-mode/EHT restriction
via a gcmp256 option.
Carlo Szelinsky [Sat, 13 Jun 2026 15:04:25 +0000 (17:04 +0200)]
realtek: add support for Hasivo S1300WP-8XGT-4S+
The Hasivo S1300WP-8XGT-4S+ is a 12-port managed switch based on the
Realtek RTL9313 (RTL931x) SoC.
Tested on hardware revision v1.02 (manufactured 2026-04).
Specifications:
- SoC: Realtek RTL9313
- RAM: 512 MB
- Flash: 32 MB SPI-NOR
- Ethernet: 8x 10GBASE-T (2x RTL8264 quad PHYs), 4x SFP+ (10G)
- Button: 1x reset
- LEDs: 1x system (green) + per-port link/activity via the SoC LED engine
- RTC: NXP PCF8563
- Management MCU (I2C 0x6F): watchdog, CPU/system temperature and fan
control (hwmon)
- UART: 38400 8N1 on the internal header
Working: switching on all copper and SFP+ ports, per-port and system
LEDs, reset button, RTC, watchdog, temperature/fan monitoring.
Not supported: PoE (the PD69x0x PSE controllers are on the PCB but not
driven), front-panel USB host.
Installation:
Netboot the initramfs image over TFTP, then run sysupgrade from OpenWrt.
Connect to the serial console (38400 8N1) and interrupt the U-Boot
autoboot to reach the prompt (press Ctrl+C, then z, then h), then boot
the initramfs image from a TFTP server:
Port 55 is front-panel port 12. Use fiber1g for a 1G SFP, fiber10g for
SFP+, and dac50cm for an SFP/RJ45 module. Once OpenWrt has booted, copy
the sysupgrade image over and flash it with sysupgrade.
MAC addresses:
The base MAC comes from the U-Boot environment variable "ethaddr" in
the u-boot-env partition (stock BDINFO). These units ship unprovisioned
(ethaddr = 00:E0:4C:00:00:00); in that case a random MAC is generated
and persisted. Per-port LAN MACs are derived sequentially.
eth0 / label u-boot-env "ethaddr" (random fallback when unset)
lan1 .. lan12 base MAC + sequential offset
Jonas Jelonek [Fri, 26 Jun 2026 18:06:22 +0000 (18:06 +0000)]
realtek: add support for Ubiquiti UniFi USW Pro XG 8 PoE
Add support for RTL9313-based Ubiquiti UniFi USW Pro XG 8 PoE switch
with 8x 10G RJ45 and 2x SFP+ ports.
Hardware
========
- RTL9313 switch SoC
- 512 MiB RAM
- 32 MiB SPI-NOR flash
- 8x 100M/1G/2.5G/5G/10G RJ45 ports via 2x RTL8264B
- PoE: 8x 802.3bt, 60W per port, 155W total budget
- 2x 1G/2.5G/10G SFP+ ports
- Buttons: 1x Reset
- LEDs:
- System LED white/blue
- RGBW LED per port
- Console: TTL 3.3V, 115200 8N1, populated 4-pin header
(device must be opened to access header)
- 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.
Known issues
============
- PoE not available, depends on WIP Realtek PSE MCU driver
- 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 overwrites 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.
(at this stage you may make backups of the flash, just to be sure)
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 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:
Then reboot the switch, it comes up in OpenWrt after reboot.
You may also install the image in any other way, just make sure to
write it to the kernel0 partition and if the image is larger than
16MiB, write the rest to the kernel1 partition, otherwise invalidate
it so U-Boot cannot boot from the second bank.
4. It is recommended to modify the bootcmd to speedup 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 to:
bootm 0xb4150000
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:
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:
Once you have a clean uImage, it can be written to the kernel partition
from within OpenWrt. If you adjusted the bootcmd during installation,
make sure to restore it to the default "bootcmd=bootubnt". After a reboot,
Ubiquiti's firmware should boot.
Or, if you did backups of the flash before, just write the backup to the
flash.
Jonas Jelonek [Sun, 5 Jul 2026 20:56:09 +0000 (20:56 +0000)]
realtek: pcs: rtl930x: some more calibration init cleanup
Some more cleanup for the calibration cleanup, removing some stray
whitespaces and collapsing subsequent writes in the same registers. The
former aren't helping anymore after the page -> named field conversion.
The latter can be collapsed because there is no reason to keep them
separate and thus, calls can be reduced.
Jonas Jelonek [Sun, 5 Jul 2026 17:47:44 +0000 (17:47 +0000)]
realtek: pcs: rtl930x: replace mdelay with msleep/usleep_range
All calibration and SerDes config code runs in process context, so
busy-waiting with mdelay is unnecessary. Use usleep_range for delays
up to 10ms and msleep for longer ones to yield the CPU instead.
Add explicit linux/delay.h include to document the dependency.
Jonas Jelonek [Sat, 4 Jul 2026 21:16:31 +0000 (21:16 +0000)]
realtek: pcs: rtl930x: add some context to calibration init
Replace SDK-style step numbering (1.1.1, 1.1.2, ...) with descriptive
section headers and inline register name comments. This makes it easier
to follow the calibration sequence without cross-referencing the SDK.
Also correct the LEQ acronym expansion and tidy up variable comments.
Jonas Jelonek [Sun, 5 Jul 2026 13:17:35 +0000 (13:17 +0000)]
realtek: pcs: rtl930x: use VTH/TAP helpers in calibration init
Replace the raw register writes in rxcal_init with the previously
cleaned-up VTH and TAP helpers. Beyond readability, this also fixes two
latent bugs in the original tap4 initialisation: tap4_even was written
twice (both to PAGE_ANA_10G_EXT 0x01[5:0]) and tap4_odd was never
written at all (PAGE_ANA_10G 0x06[11:6]). Using tap_set_value(sds, 4,
0, 0) writes both fields correctly.
Also apply stage-then-latch ordering to the VTH init: write the value
registers before asserting the manual bit, consistent with the rest of
the calibration lock path.
Jonas Jelonek [Sun, 5 Jul 2026 13:07:12 +0000 (13:07 +0000)]
realtek: pcs: rtl930x: cleanup TAP helpers
Split tap_manual() into tap_set_adapt() and tap_set_value(), separating
mode control from value writes. Replace manual sign-magnitude bit
manipulation with rtpcs_sign_mag_encode/decode helpers. Update tap_get()
to use individual signed output pointers instead of an array and add
error propagation. Apply stage-then-latch ordering consistently: value
is written before the manual bit is set.
Remove the usleep from tap_set_adapt(enable=true). Callers already
carry explicit delays: vth_tap0_adapt_lock has msleep(200) and
dfe_taps_adapt has msleep(30) after enabling auto-adapt. The 10ms per
call was redundant and added 40ms to dfe_taps_adapt needlessly.
Jonas Jelonek [Sun, 5 Jul 2026 10:42:35 +0000 (10:42 +0000)]
realtek: pcs: rtl930x: cleanup VTH helpers
Split vth_manual() into vth_set_adapt() and vth_set_value(), separating
mode control from value writes, consistent with DCVS and LEQ helpers.
Rename vth_get() to match and switch from an array parameter to
individual pointers. Invert the manual boolean to 'enable' (true means
auto-adapt is running). Add error propagation throughout and demote the
read-out print from pr_info to pr_debug.
Remove the usleep from vth_set_adapt(enable=true). The only caller is
vth_tap0_adapt_lock which already has an explicit msleep(200) to wait
for adaptation to complete, making the embedded 10ms redundant. Delay
belongs at the call site, not baked into the setter.
Jonas Jelonek [Sun, 5 Jul 2026 09:59:25 +0000 (09:59 +0000)]
realtek: pcs: rtl930x: cleanup LEQ helpers
Split leq_manual() into leq_set_adapt() and leq_set_coef(), separating
mode control from coefficient writes, consistent with the DCVS helpers.
Rename leq_get() to leq_get_coef() and leq_get_bin() to
leq_get_coef_bin() to match. Add error propagation throughout.
Jonas Jelonek [Sun, 5 Jul 2026 17:15:21 +0000 (17:15 +0000)]
realtek: pcs: rtl930x: use DCVS helpers in calibration init
Replace the nine raw register writes that enable auto-adapt for all six
DCVS channels with a loop over dcvs_set_adapt(), consistent with how
TAP and VTH init was already converted.
Jonas Jelonek [Sat, 4 Jul 2026 22:15:48 +0000 (22:15 +0000)]
realtek: pcs: rtl930x: cleanup DCVS helpers
Split the DCVS setter into two functions, separating mode control from
coefficient setting. The old pattern, combining everything in one
function, was still kept from the SDK but is rather confusing and makes
the function rather complex. Splitting this simplifies it a lot.
Cleanup the DCVS getter, making it consistent with the setters. Though
not used right now, kept for documentation purpose. So at least keep it
in a good style.
Remove the usleep from dcvs_set_adapt(enable=true). There is no lock
flow for DCVS that polls a result after enabling auto-adapt, so no
caller needs the delay. rxcal_init also enables VTH and TAP auto-adapt
via the load_in_init bulk write with no delay, confirming it is not
needed here either.
Jonas Jelonek [Sat, 4 Jul 2026 21:53:49 +0000 (21:53 +0000)]
realtek: pcs: rtl930x: fix DCVS setter
The (currently unused) DCVS setter (_dcvs_manual) is still based on the
XGS1210 SDK. Comparing this with other SDKs we have available (DMS1250,
TEG7124WS), a discrepancy between the setters can be seen. The variant
from XGS1210 SDK uses different fields for DCVS0 and DCVS4. They do not
match the other SDK variants, and also not the settings in
do_rx_calibration_1 where DCVS is initialized.
Adjust that to what the majority of SDK variants uses and to what makes
it consistent overall.
Jonas Jelonek [Sat, 4 Jul 2026 23:58:24 +0000 (23:58 +0000)]
realtek: pcs: rtl930x: carve out debug selection
The three SerDes writes setting a debug output is heavily used by the
calibration code. But right now, it is duplicated in every user site. To
reduce duplication, carve out into a dedicated helper.
Jonas Jelonek [Sun, 5 Jul 2026 17:17:30 +0000 (17:17 +0000)]
realtek: pcs: rtl930x: rename last numbered calibration function
One calibration function was renamed from the numbered naming before,
mostly because its full purpose wasn't known yet. This has changed now,
so rename that function to "rxcal_init" to reflect what it's doing.
Evan Kinney [Wed, 17 Jun 2026 01:11:11 +0000 (21:11 -0400)]
realtek: generate lan_list from device tree to avoid startup race
Currently, 02_network discovers lan ports from /sys/class/net/lan*.
When booting on some devices, DSA ends up registering ports _after_
config generation has started, producing a board.json/network config
that is missing those ports.
Read labels from the device tree instead; they already exist as static
board data. If they are missing, fall back to the previous behavior.
Verified on a XikeStor SKS8300-8T (a rtl930x platform).
qualcommbe: ipq9574: align USXGMII bring-up with SSDK
Align the USXGMII configuration sequence with the vendor SSDK:
- Reset the PCS PLL by programming the whole reset register with the
documented assert and release values and 100ms holds, instead of
toggling a single bit for 1ms and relying on the power-on state of
the remaining analog enables.
- Keep the uniphy port clocks disabled across the reconfiguration and
re-enable them after calibration, before releasing the XPCS reset.
- Select in-band link detection explicitly rather than the SFP
loss-of-signal input, which does not exist on non-SFP ports.
- Wait for the 10GBASE-R receiver to link before enabling the USXGMII
adaptation layer. Best-effort, since the PHY SerDes may only come
up later.
Other interface modes keep the previous behaviour.
qualcommbe: ipq9574: fix MISC2 mode field and cover USXGMII
The MISC2 phy mode field is modelled as two bits at the wrong offset:
the hardware field is three bits wide and starts one bit lower. The
SGMII and 2500BASE-X values only come out right because the power-on
default happens to keep the missed bit set, and USXGMII is not
programmed at all, leaving the uniphy in its power-on SGMII
personality.
Model the field at its documented position, add the USXGMII mode
value and write the rate field explicitly instead of relying on its
power-on default, matching the values the vendor SSDK programs.
qualcommbe: ipq9574: pulse uniphy sys/soft resets during config
The uniphy never receives a software reset pulse during interface mode
configuration. The vendor SSDK asserts the GCC system reset and the
NSSCC soft reset together for 100ms on every uniphy mode change;
without the pulse, parts of the uniphy analog block can remain in
their power-on state.
Pulse both resets, when the devicetree provides them, after the mode
is programmed. Both resets are optional so existing devicetrees keep
working.
Some board designs feed an external PHY its reference clock from the
uniphy 25MHz clock output instead of a local crystal. Enable the
output when the devicetree opts in with "qcom,uniphy-clkout-25mhz".
The clock output register only becomes writable once the PLL reset
and calibration have completed, so program it at the end of the mode
configuration rather than at probe time.
The XPCS signals USXGMII in-band autonegotiation completion through an
interrupt that is never enabled, waited for or acknowledged, so rate
adaptation never starts and the MAC receives nothing even though the
SerDes achieves block lock. The advertised speed and duplex are also
left at their reset values while autonegotiation runs.
Follow the vendor SSDK sequence: enable the completion interrupt and
advertise 10G/full duplex when configuring the PCS, and on link-up
restart the in-band autonegotiation, wait for completion and
acknowledge it before programming the negotiated speed. The wait is
best-effort, as in the vendor driver.
Each uniphy has, besides the XPCS reset, a system reset in the GCC and
a soft reset in the NSSCC. The vendor driver pulses both on every
interface mode change as part of the uniphy bring-up. Describe them,
and name the resets while at it, so the PCS driver can pick them up.
Marius Dinu [Sat, 4 Jul 2026 20:28:33 +0000 (23:28 +0300)]
kernel-packages: video: remove path variables
These path names are unlikely to change. There is no need for variables.
Tested on Turris Omnia, but not all of these drivers were tested. Variables
were replaced automatically (search-and-replace in text editor). There
shouldn't be any problems.
Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro>
Andris PE [Wed, 1 Jul 2026 09:03:50 +0000 (09:03 +0000)]
kernel: minimize kmod-sched-connmark dependencies
Remove iptables kmod dependency from kmod-sched-connmark.
Both dependents
package/network/config/qos-scripts
../packages/net/trafficshaper
Already pull in ipt kmods via iptables-mod-conntrack-extra
Permits "clean" nftables migration at
https://github.com/openwrt/packages/pull/29830
This concatenates the ubi partition (19.9 MiB) with the ecos partition
(96.1 MiB) into a single virtual MTD device for UBI, giving ~116 MiB
of usable flash space.
Rany Hany [Sat, 4 Jul 2026 23:58:34 +0000 (23:58 +0000)]
intel-microcode: fix build error on rebuild
When rebuilding the package, iucode_tool fails with a "File exists"
error if the directory already contained firmware from the previous
build (incl. in the successful build case).
Fix this by removing the directory before invoking iucode_tool.
Fixes the following build error:
iucode_tool: 06-0f-02: cannot write to, or create file: File exists
make[2]: *** [Makefile:57: .../.built] Error 2
Cherry pick the patches recommended in the hostapd security advisory
2026-1:
https://w1.fi/security/2026-1/missing-ml-parsing-validation.txt
Vulnerability
Vulnerabilities in parsing and use of received multi-link (MLO/EHT/IEEE
802.11be/Wi-Fi 7) information has been identified in hostapd and
wpa_supplicant. These issues show up in various cases where frames
including information on affiliated links are parsed and processed in
both AP and STA modes. The issues can result in process termination due
to buffer read overflow checks and memory corruption.
The issues for AP mode (hostapd or wpa_supplicant) can result in
denial-of-service attacks due to process termination and small memory
corruption that could theoretically cause other issues, but it does not
seem likely that those could be exploiting in practice. Affected areas
can be reached by sending invalid Management frames without needing
authentication or user action on the target device.
mediatek: filogic: add USB VBUS regulator for Globitel BT-R320
USB VBUS on the BT-R320 is controlled by GPIO14.
Add a fixed regulator and hook it up to the xHCI controller.
GPIO_ACTIVE_HIGH was tested on the device: the dummy regulator warning is gone and a USB device enumerates.
mediatek: filogic: fix Globitel BT-R320 recovery image name
The initramfs image name already contains "-initramfs". Using "-initramfs-recovery.itb" as the suffix makes the BT-R320 recovery artifact contain it twice.
Use "-recovery.itb" instead.
Fixes: a3105d3f9573 ("mediatek: filogic: add support for Globitel BT-R320") Signed-off-by: solodecode <zikwarface134@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24059 Signed-off-by: Robert Marko <robimarko@gmail.com>
John Audia [Sat, 4 Jul 2026 10:22:06 +0000 (06:22 -0400)]
dnsmasq: migrate dhcpv4/dhcpv6 default on upgrade
Commit 6f30f08d0e ("dnsmasq: add fallback for default dhcpv4/dhcpv6
values") changed dnsmasq.init to default the 'dhcpv4'/'dhcpv6' UCI
options to 'disabled' when a 'config dhcp' section leaves them unset:
The intent was to match odhcpd, which already treats an unset value
as disabled, so both backends behave the same way for newly created
configs. Its companion commit 85767ac8fe added explicit
'option dhcpv4/dhcpv6 server' lines to the stock 'lan' section in the
packaged dhcp.conf template, which covers fresh installs.
Neither commit accounts for configs that predate the change. Before
it, an unset dhcpv4/dhcpv6 option was implicitly treated as enabled,
so it was common (and still is, on any router upgraded from before
this landed) to have 'config dhcp' sections for additional
interfaces/VLANs with no explicit dhcpv4/dhcpv6 option at all. After
the change, dnsmasq.init silently skips '--dhcp-range' for every one
of those sections:
if [ "$dhcpv4" != "disabled" ]; then
...
fi
The result: any interface whose dhcp section never needed the option
before stops handing out leases entirely, with nothing logged beyond
a normal dnsmasq startup, while sections that happen to already carry
an explicit 'server' value keep working. On a router with several
VLANs this looks exactly like "DHCP only works on one interface."
Fix by shipping a one-time /etc/uci-defaults migration, matching the
existing 50-dnsmasq-migrate-resolv-conf-auto.sh /
50-dnsmasq-migrate-ipset.sh pattern in this package: for every
'config dhcp' section, if dhcpv4/dhcpv6 is unset, explicitly set it
to 'server', preserving the pre-6f30f08d0e behavior for existing
configs. Sections that already set the option (or set 'disabled'
deliberately) are left untouched, and sections that never reach the
check (e.g. 'wan' with 'option ignore 1') are unaffected.
Shiji Yang [Fri, 3 Jul 2026 14:56:39 +0000 (22:56 +0800)]
uboot-at91: fix build failure with GCC 14.4
It seems that GCC 14.4 will generate larger binary compared to the
GCC 14.3 on ARM32 platforms. We have to increase the maximum allowed
SPL size to fix build errors.
Robert Marko [Wed, 1 Jul 2026 18:19:21 +0000 (20:19 +0200)]
microchipsw: configure TAS port link speed
On the TSN and RED variants of SparX-5 and LAN969x TAS (Time-Aware Shaper)
is present in the silicon.
Currently, the driver does not use configure it at all, which means that
the TAS_PROFILE_CONFIG.LINK_SPEED[1] value is left at the default of 3
which means that its configured for 1 Gbps.
So, running iperf between two 10G switch ports will result in only 940-ish
Mbps while we should be getting around 9.3 Gbps.
Correctly populating the TAS_PROFILE_CONFIG.LINK_SPEED[1] with the current
port speed fixes this issue and we achieve around 9.4 Gbps between two 10G
switch ports.
So, port the TAS port link speed setting from the vendor BSP 6.18 kernel[2]
Lech Perczak [Tue, 14 Nov 2023 18:44:43 +0000 (19:44 +0100)]
imx: cortexa7: support camera on TechNexion PICO-PI-IMX7D
Enable device packages required for camera support and add relevant device
tree nodes.
The drivers probe and connect properly, but it currently only supports
uncompressed UYVY in 2592x1944, 1920x1080 and 1280x960 resolutions, so I
had to use ustreamer to get the stream over network:
To get the camera working, the following extra packages are needed:
kmod-mux-mmio kmod-video-imx7-csi kmod-video-imx-mipi-csis kmod-video-mux \
kmod-video-ov5645
To set up the capture, you need to set up the links and formats across
the pipeline, for example:
Richard Huynh [Thu, 16 Apr 2026 11:40:53 +0000 (21:40 +1000)]
wifi-scripts: add EHT beamforming options to hostapd config
Some EHT options like beamformer/beamformee
are disabled by default in hostapd.conf
Read the EHT Phy Cap structure and enable/disable
switches within the hostapd.conf for capable hardware.
Without this EHT SU beamformer/beamformee and MU
beamformer capabilities are omitted from AP beacons,
even if the driver reports the hardware as capable.
Matthias Urlichs [Mon, 22 Jun 2026 09:44:20 +0000 (11:44 +0200)]
ath79: add support for Ubiquiti NanoStation Loco M (XW v2)
This commit adds support for the NanoStation Loco M2/M5 XW devices
on the ath79 target with test date (label on the packaging, not the
device) later than October 2017.
To discover whether you have the new version, open a console on the
stock web interface and run `dmesg | grep AR803`. New versions print
AR8035, v1 shows AR8032.
- Use a pointy tool (e.g., pen cap, paper clip) and keep the reset
button on the device pressed
- Power on the device via PoE (keep reset button pressed)
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button
- The device starts a TFTP server at 192.168.1.20
- Set a static IP on the computer (e.g., 192.168.1.21/24)
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> put openwrt-ath79-generic-xxxxx-ubnt_nanostation-loco-m-xw-v2-squashfs-factory.bin
MAC addresses: stored on Flash, in the "art" partition.
solodecode [Sat, 20 Jun 2026 16:47:40 +0000 (19:47 +0300)]
mediatek: filogic: fix Globitel BT-R320 FIT rootfs mapping
Globitel BT-R320 boots the sysupgrade FIT from the eMMC production
partition with root=/dev/fit0.
The device tree did not describe the production GPT partition and
/chosen/rootdisk did not point at the FIT container. fitblk then had no
rootdisk match and the board stopped at:
Waiting for root device /dev/fit0...
Describe the eMMC GPT partitions, set /chosen/rootdisk to production,
and use the FIT sysupgrade path.
Fixes: a3105d3f9573 ("mediatek: filogic: add support for Globitel BT-R320") Signed-off-by: solodecode <zikwarface134@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23895 Signed-off-by: Robert Marko <robert.marko@sartura.hr>
ath79: fix Ethernet auto-negotiation on Ruckus ZoneFlex 7025
On the ZoneFlex 7025 the uplink port (eth0) is connected to PHY 4 of
the AR7240 built-in switch. This PHY erroneously advertises
1000baseT/Full capability, even though the AR7240 built-in switch only
supports 10/100 Mbps.
Because of the bogus gigabit capability, phylib performs 1000BASE-T
master/slave resolution against the PHY's non-functional gigabit
registers, which never completes. Auto-negotiation then fails: the
link flaps between speeds or never comes up at all, while a manually
forced fixed speed works fine.
Cap the PHY at 100 Mbps so the gigabit capability is removed and the
master/slave resolution path is skipped. eth0 then auto-negotiates
reliably to 100 Mbps full-duplex.
Przemek Rudy [Mon, 23 Feb 2026 10:44:17 +0000 (11:44 +0100)]
mvebu: MikroTik: add support for RB5009UPr+S+IN
The MikroTik RB5009UPr+S+IN is a multigig router based on the Marvell
Armada 7040 SoC, sharing the same hardware base as the RB5009UG+S+IN
with added PoE-out support on all ethernet ports.
Specification:
- SoC : Marvell Armada 7040 (88F7040), 4x Cortex-A72
- CPU frequency : 350-1400 MHz
- RAM : 1 GB
- Flash : 16 MB SPI NOR + 1 GB NAND
- Switch : Marvell MV88E6393X
- Ethernet : 1x 2.5G (p1, QCA8081), 7x 1G (p2-p8), 1x SFP+ 10G
- PoE-in : 802.3af/at on p1, 24-57V
- PoE-out : 802.3af/at on p1-p8, 130 W total
- Power : DC jack / 2-pin terminal / PoE-in, 24-57V
- USB : 1x USB 3.0 type A, max 1.5 A
- LEDs/Keys (GPIO): 4x/1x
- UART : MikroTik SPI/UART combo header (10-pin, 2.0mm pitch)
- assignment : GND Vcc Rx ? GND / CLK DO /CS Tx DI (top view)
- settings : 115200n8
Flash instruction using initramfs image:
RouterBOOT cannot boot the OpenWrt kernel directly. A U-Boot loader
(u-boot.elf) is installed as an intermediary: RouterBOOT loads
u-boot.elf, which then loads the OpenWrt initramfs image.
1. Rename the downloaded initramfs image, removing the version number,
to: openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-uImage.itb
2. Set up a BOOTP/TFTP server serving u-boot.elf, with the renamed
initramfs image in the same directory
3. Power off the router, hold the reset button (front panel), power on
and keep holding until the initramfs image has been served, then
release
4. The router boots the initramfs image, reachable at 192.168.1.1
5. Log in via SSH, install U-Boot, wipe NAND and flash OpenWrt:
Przemek Rudy [Mon, 23 Dec 2024 19:28:12 +0000 (20:28 +0100)]
mvebu: rename generic rb5009 to rb5009ug
Specialize RB5009UG model from generic RB5009.
Signed-off-by: Przemek Rudy <prudy@protonmail.com>
[carlo@common-net.org: fixed model name and backward compatibility ] Signed-off-by: Carlo Filippi <carlo@common-net.org> Signed-off-by: Sm00shed <sm00shed@posteo.de> Link: https://github.com/openwrt/openwrt/pull/23698 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
YaleiZang [Tue, 30 Jun 2026 08:13:01 +0000 (16:13 +0800)]
airoha: remove KERNEL_LOADADDR from airoha_an7583-evb device definition
Delete the KERNEL_LOADADDR assignment from the airoha_an7583-evb device definition.
The kernel load address is now centrally managed in image Makefile with, just using default load address:
This ensures the load address configuration is maintained in a single location.
Removing the duplicate assignment prevents confusion and potential misconfiguration.
Rosen Penev [Sun, 28 Jun 2026 21:09:06 +0000 (14:09 -0700)]
apm821xx: move PHY/DSA drivers to DEVICE_PACKAGES on nand boards
Only the devices that actually have these PHYs and DSA switches
should carry the kernel modules, instead of baking them into the
kernel for all nand boards.
These devices have no space constraints, so any size increase is
meaningless.
Dmitry Mostovoy [Sat, 9 May 2026 18:56:45 +0000 (14:56 -0400)]
mediatek: add cudy m3000-v2-yt8821 ubootmod
RAM: ESMT M15T2G16128A-DEB DDR3 1866 MT/s
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdinfo" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_m3000-v2-yt8821-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_m3000-v2-yt8821-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_m3000-v2-yt8821-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Dmitry Mostovoy [Sat, 9 May 2026 15:56:40 +0000 (11:56 -0400)]
mediatek: add cudy m3000-v1 ubootmod
RAM: ESMT M15T2G16128A-DEB DDR3 1866 MT/s
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdinfo" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_m3000-v1-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_m3000-v1-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_m3000-v1-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Sven Eckelmann [Mon, 22 Jun 2026 13:10:38 +0000 (15:10 +0200)]
rtl826x-firmware: ship rtl8261n and rtl8264b in single firmware package
The firmware loading does not depend (solely) on the PHY id. The driver
needs to read out the vendor version id of the PHY before it can decide
which firmware file needs to be loaded.
A split in an RTL8261N and an RTL8264B firmware package is therefore
misleading. And it could even be that a product ships an RTL8264B but
switches the revision of the chip in the middle of its product lifetime. In
this case, the first identification based on the chip ID or the actual chip
ID for the OpenWrt porter might fail for another user with a later/earlier
produced device.
Shipping both files in the same package avoids this problem. Only the "low
power" firmware package is slightly misleading because there is only a
RTL8261N firmware binary for low power but no corresponding RTL8264B
version. It will ship simply the non-low power version for RTL8264B.
Suggested-by: Jonas Jelonek <jelonek.jonas@gmail.com> Signed-off-by: Sven Eckelmann <sven@narfation.org> Link: https://github.com/openwrt/openwrt/pull/23947 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Carlo Szelinsky [Tue, 9 Jun 2026 19:42:40 +0000 (21:42 +0200)]
generic: net: phy: realtek: select rtl826x phy patch table by chip version
The in-tree realtek 5G/10G driver picks the firmware patch table from the
PHY ID (RTL8264 -> rtl8264b.bin). The vendor driver instead picks it from
VEND1 0x104[2:0] (0 = RTL8264B, else RTL8261N-C), independent of PHY ID.
On the S1300WP the RTL8264 dies read 0x104=0xf802 ([2:0]=2), so they need
the RTL8261N-C table; the RTL8264B table leaves the PCS unlocked (0xA600
stuck 0x1000) and config_init fails with -ETIME. Read 0x104[2:0] and load
rtl8261n.bin when non-zero. Boards with such a die must ship rtl8261n.bin.
Fixes: 6369c9e5c799 ("generic: net: phy: realtek: add 5G and 10G PHY support") Co-authored-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Carlo Szelinsky <github@szelinsky.de> Link: https://github.com/openwrt/openwrt/pull/23947 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
projects / thirdparty / openwrt.git / log
