Fix and improve support for AN7583. Muxing of SPI, MDIO and I2C is
now fully supported and working.
Fix I2C1 in master mode on AN7581. (this allows to replace the i2c-gpio
driver on Nokia Valyrian with the proper i2c-mt7621 driver).
Fix non-working switching of GPIO direction if GPIO control register were
already modified by bootloader and pinctrl would create a reserved
state. All GPIO control registers have two bits per GPIO but the driver
only set one which is now fixed.
Fix problem were a pinmux config or GPIO mode cannot be applied if pin
control register were already modified by bootloader. The driver expects
all pin control registers to have their reset default value. Now the
driver forces that reset default value during probe.
Worth to mention that on AN7583 the GPIO mode and alternate pin modes
are reversed in the reset default value. To achieve same behaviour as on
AN7581 (GPIO mode by default, board DTS applies pinmux), the default
value enforced during probe enables all GPIO mode bits. As consequence
all AN7583 board DTS need to explicitely activate mdio0 or spi pin
groups.
airoha: backport pinctrl patches from Linux mainline
Backport missing pinctrl patches that has been accepted in Linux
v6.19 and v7.2.
This includes moving the Airoha pinctrl driver from
drivers/pinctrl/mediatek to drivers/pinctrl/airoha. Due to this,
all existing pinctrl patches needed a refresh.
Downstream patches may change the output. If the GCC version doesn't
incooperate the patches somehow (hash, git commit, ...), ccache may not
invalidate existing cache.
Document the existing properties supported by the legacy RTL8367B
switch driver, including MDIO and GPIO SMI access, optional reset and
internal MDIO bus descriptions, external interface configuration, and
board-specific post-initialization register/value pairs.
kernel: rtl8367b: support post-init register writes
Allow boards to provide optional register/value pairs through the
realtek,init-regs property. Apply them after the chip-specific
initialization table and before configuring the external interface.
Keep the property a no-op when absent. Reject malformed, oversized or
non-16-bit entries, and propagate register write failures. While at it,
remove a redundant trailing blank line at the end of the file.
Georgi Valkov [Thu, 16 Jul 2026 09:28:00 +0000 (12:28 +0300)]
mac80211: mwifiex: replace one-element arrays with flexible array members
Replace deprecated one-element arrays with flexible array members.
CONFIG_FORTIFY_SOURCE reports the following warning when
one-element arrays are used as variable-length buffers:
sta_cmd.c:1033 mwifiex_sta_prepare_cmd
memcpy: detected field-spanning write (size 84) of single field
"domain->triplet" at .../marvell/mwifiex/sta_cmd.c:1033 (size 3)
Convert affected structs to use flexible array members.
- Preserve existing wire layouts.
- Use DECLARE_FLEX_ARRAY() for structs inside affected unions.
Add a change_mtu operation, so the length the switch may deliver to the
CPU follows the conduit MTU instead of keeping the value programmed when
the interface came up.
To avoid trouble with the receive buffer, adapt the head of line budget
along with it. Those registers limit how many packets the hardware may
append to a receive ring, and deriving that limit from a frame of
maximum length makes the smallest MTU pay the price of the largest. With
400 byte fragments a 1626 byte frame occupies five of them, which leaves
128 / 5 = 25 packets per ring, while the 1530 byte frame of a tagged
conduit at its idle MTU needs four and fits 32.
The two limits move in opposite directions, so the order matters: on the
way up the budget shrinks before the switch is allowed to hand over
larger frames, which keeps the ring from ever running a budget meant for
smaller ones. On the way down it grows only after the switch has stopped
handing over the larger frames, which narrows that window rather than
closing it, as the ring may still hold frames of the previous size. The
pair runs under the lock the rest of the driver programs those registers
with, as the transmit watchdog is not serialised against an MTU change.
The budget comes from the config, one function per family, and opening
the interface calls it too: RTL83xx has none to resize, as its rings are
free floating, so it writes the ring size of zero that its reset paths
used to write themselves.
Nothing else has to follow, as the receive buffers are of a fixed size.
The largest MTU comes from the config too, one value per family: 10000
bytes on RTL838x and 12288 on the others, less the frame overhead. Those
are the limits the DSA driver already declares in its rmon ranges. A
frame must also fit into a single skb, whose linear part and fragments
hold 400 bytes each, so the operation refuses above an MTU of 7174 on
every family, well below what the switches would take. The fragment
size carries a TODO of its own, and raising it lifts that bound towards
the hardware one.
That remaining window is why every accepted change carries a warning. A
closed interface has neither a ring to protect nor registers worth
touching, as opening it derives both limits from the MTU anyway, so
leave the hardware alone while it is down. That also keeps the warning
out of the boot log, where dsa_conduit_setup() sets the tagging overhead
on a conduit that carries no traffic yet.
Tested on an RTL9303 (Hasivo S1100W-8XGT-SE, RTL8264B PHY, USXGMII).
Both limits follow every MTU as computed, read back from the switch:
where the previous static sizing programmed 25 packets per ring at every
MTU. An MTU of 7175 is refused, and one of 9000, which the family
ceiling would allow, reaches the operation and is refused there: no
warning is logged for it, where an accepted change logs one, and the
boot log carries none at all. Raising the MTU to 1600 while the
interface is down leaves the registers at 1530 and the budget at 32
packets and logs nothing, while bringing it up afterwards programs 1626
and 25, so the change is deferred rather than lost. Traffic keeps
flowing across the changes: a 102 byte frame is answered five times out
of five at each step, while a 1046 byte one passes at MTU 1504, stops at
MTU 1000, whose limit of 1026 it exceeds, and passes again once the MTU
is back. Sixty alternating changes between two MTUs complete with
nothing logged, on a build with spinlock debugging enabled.
realtek: eth: bound the packet length at the CPU port
The length of the frames the switch may hand to the CPU has nothing to
do with the MTU the conduit runs at. The registers holding it keep
whatever the bootloader left, and the only other mechanism in the path
is the DMA truncation length, which does not drop what exceeds it: it
cuts the frame short and hands the remains to the stack. Nothing in the
target programs either of them from the MTU.
Add a per SoC set_max_packet_length() that programs those registers from
the conduit MTU and turns the truncation off, so an oversized frame is
dropped rather than delivered mutilated. The registers differ per
family, from the maps at svanheule.net, and every length field is 14
bits wide:
Longan is the only family whose CPU register carries a single field,
covering what the switch sends towards the CPU. What it takes from the
CPU lives in the port register of that port, 0x326c + port * 64, whose
two fields hold the length for the slow and the fast link speeds. The
vendor SDK reads the slow one there; both are programmed, as the driver
does not know at which speed the internal port runs. Mango keeps its
port registers in an array documented for ports 0 to 55, one short of
its CPU port, so there the CPU register alone holds both directions.
Characterised on an RTL9303 (Hasivo S1100W-8XGT-SE) by lowering the
truncation length and the maximum length of the CPU port in turn, while
frames of growing size were sent into a user port. The largest frame
that survives is the maximum length minus four, and the truncation
length minus eight, both constant at three settings of each register.
Beyond that boundary the truncation delivers a frame cut short, seen on
the conduit as 992 bytes where 1014 were sent, while the maximum length
register lets nothing through.
Read at the U-Boot prompt on the same board, reproduced across two
boots, the bootloader leaves 0xa3a0 at 0x600, 0x396c at 0x0c003000 and
DMA_IF_CTRL at 0x06400000, a truncation length of 1600 with every enable
still clear. With this patch and the conduit at its idle MTU of 1504,
both length registers read 1530, while DMA_IF_CTRL has its truncation
bit clear and the transmit and receive enables set.
Compile-tested only on RTL838x/839x/931x, where the offsets come from
the maps alone and the effect has not been observed. This changes what
those boards do at every interface open, not only when the MTU changes,
so testing from their owners is welcome. On RTL838x the transmit length
lives in a register of its own:
https://svanheule.net/realtek/maple/register/dma_if_pkt_tx_fltr_ctrl
Georgi Valkov [Sun, 12 Jul 2026 20:14:57 +0000 (23:14 +0300)]
mac80211: mwifiex: fix freeze for 60 seconds caused by request_firmware
Fix regression in rgpower table loading, caused by using
request_firmware(): when the requested firmware does not exist, e.g.
nxp/rgpower_WW.bin does not exist on OpenWrt builds for WRT3200ACM,
request_firmware() falls back to firmware_fallback_sysfs(), which expects
the firmware to be provided by user space using SYSFS. No such utility is
provided in this configuration, so the entire system locks up for 60
seconds, until the request times out. During this time, no other log
messages are observed, and the device does not respond to commands over
UART.
The request_firmware() call is performed in the following context:
current->comm kworker/1:2 in_task 1 irqs_disabled 0 in_atomic 0
Fixed by using request_firmware_direct(). This prevents fallback to SYSFS,
and avoids delay. The rgpower table is optional. The driver falls back
to the device tree power table if the firmware is not present.
The error code is printed for debugging and returned to the caller,
which only cares for success or failure, so there are no side effects.
Link: #24205 Fixes: #24434 Fixes: https://forum.openwrt.org/t/25-12-0-slow-boot-on-linksys-wrt3200acm/247751 Fixes: https://github.com/torvalds/linux/commit/7b6f16a258065f85793fb2597a290041c1e3d201 Signed-off-by: Georgi Valkov <gvalkov@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24205 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The board enables gdm1 in its DTS, but U-Boot v2026.07 ships
arch/arm/dts/an7581-u-boot.dtsi, which is appended to the end of the
board DTS and declares gdm1 with status = "disabled". The board setting
is overridden and U-Boot ends up without a network device.
Add a board specific an7581-w1700k-ubi-u-boot.dtsi re-enabling gdm1.
U-Boot only pulls in the first matching *-u-boot.dtsi (firstword in
scripts/Makefile.lib), so the board file must include the SoC one
explicitly, otherwise the entire an7581 U-Boot glue is dropped along
with it: uart1 bootph-all, the eth/pcs/snfi/mmc nodes and the ATF
reserved memory.
This is the same fix that was confirmed to restore networking on the
Nokia XG-040G-MD. It is compile tested only and verified by inspecting
the generated DTB - I have no W1700K hardware, so it is unverified on
the actual device and needs testing by someone who has one.
Fixes: baeacca59889 ("uboot-airoha: update to v2026.07") Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24410 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
U-Boot v2026.07 ships arch/arm/dts/an7581-u-boot.dtsi, which declares
gdm1 with status = "disabled". That file is appended to the end of the
board DTS, so it overrides the MAC enabled by the board and U-Boot ends
up without a network device:
No ethernet found.
Add a board specific an7581-nokia-xg-040g-md-u-boot.dtsi re-enabling
gdm1. U-Boot only pulls in the first matching *-u-boot.dtsi (firstword
in scripts/Makefile.lib), so the board file must include the SoC one
explicitly, otherwise the entire an7581 U-Boot glue is dropped along
with it: uart1 bootph-all, the eth/pcs/snfi/mmc nodes and the ATF
reserved memory. Same approach as en7581-evb and Nokia Valyrian.
Tested on Nokia XG-040G-MD: TFTP recovery boot works again.
Fixes: baeacca59889 ("uboot-airoha: update to v2026.07") Closes: https://github.com/openwrt/openwrt/issues/24385 Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24410 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
scripts: dl_github_archive: fix zstd args passed to tar
The multi-word zstd option '-I zstd -T0 --ultra -20' was appended as a
single argv element. subprocess passes each list element as one argv
entry, so tar received the whole string as one argument and failed to
recognize it. Split into separate '-I' and 'zstd -T0 --ultra -20'
elements so tar correctly interprets the compressor command.
Peter Putzer [Sat, 25 Jul 2026 10:28:06 +0000 (10:28 +0000)]
realtek: add support for ZyXEL GS1900-8HP B2
The ZyXEL GS1900-8HP B2 is an 8-port gigabit switch with PoE+ support. It's a new
hardware revision that uses the `realtek,pse-mcu-gen2` PSE dialect with 115200 baud
like the GS1900-10HP B1. Other hardware changes are unknown, but the switch works
fine using the pre-PSE `zyxel,gs1900-8hp-b1` image with the `realtek-poe` user-space
PoE implementation.
The installation instructions from the initial support for the A1 and B1 revisions
still apply (https://github.com/openwrt/openwrt/commit/c4bfe68c83910e613f07350587a8709a16bd1ffa):
* Configure your client with a static 192.168.1.x IP (e.g. 192.168.1.2).
* Set up a TFTP server on your client and make it serve the initramfs
image.
* Connect serial, power up the switch, interrupt U-boot by hitting the
space bar, and enable the network:
> rtk network on
* Since the GS1900-10HP is a dual-partition device, you want to keep the
OEM firmware on the backup partition for the time being. OpenWrt can
only boot off the first partition anyway (hardcoded in the DTS). To
make sure we are manipulating the first partition, issue the following
commands:
> setsys bootpartition 0
> savesys
* Download the image onto the device and boot from it:
> tftpboot 0x84f00000 192.168.1.2:openwrt-realtek-generic-zyxel_gs1900-8hp-b2-initramfs-kernel.bin
> bootm
* Once OpenWrt has booted, scp the sysupgrade image to /tmp and flash it:
> sysupgrade /tmp//tmp/openwrt-realtek-generic-zyxel_gs1900-8hp-b2-squashfs-sysupgrade.bin
Alternatively, after factory-resetting the switch, you can:
* Log in to OEM management web interface. It should be at http://192.168.1.1
* Navigate to `Maintenance > Firmware > Management`
* If "Active Image" has the first option selected, OpenWrt will need to be
flashed to the "Active" partition. If the second option is selected, OpenWrt
will need to be flashed to the "Backup" partition.
* Navigate to `Maintenance > Firmware > Upload`
* Upload the initramfs-kernel.bin file by your preferred method to the previously
determined partition. When prompted, select to boot from the newly flashed image,
and reboot the switch.
* Once OpenWrt has booted, scp the sysupgrade.bin image to /tmp and flash it thought SSH.
- OpenWrt does not include openssh-sftp-server by default. If your SCP client fails due
to lacking an SFTP server on the device, consider using the legacy SCP protocol
instead. With OpenSSH's scp this can be done by adding the -O option on the command
line.
- `sysupgrade -n /tmp/<sysupgrade file name>`
* It may be necessary to restart the network (/etc/init.d/network restart) on the running
initramfs image.
See the GS199-8HP A1 wiki page for more information (https://openwrt.org/toh/zyxel/gs1900-8hp_v1).
realtek: convert to generic machine initialization
Upstream has implemented MACH_REALTEK_RTL with the MIPS generic
startup framework. Until now OpenWrt disables that with a patch
and instead uses dedicated legacy startup sources.
Convert to upstream startup and take over the missing downstream
bits from the legacy code. Due to the complex nature of this patch
only focus on board-realtek.c for now. Moving other pieces around
(like headers) needs to be done in a separate patch.
Andrew LaMarche [Sun, 26 Jul 2026 15:35:00 +0000 (15:35 +0000)]
realtek: add support for Hasivo S1100WP-8XGT-SE switch
This commit adds support for Hasivo S1100WP-8XGT-SE switch. It is
identical to the S1100W-8XGT-SE, except it also has 2x HS104 chips for
PoE delivery.
Device specification
--------------------
SoC Type: RTL9303
RAM: Samsung K4B461646E-BYKO (512MB)
Flash: Fudan FM25Q128A (16 MB)
Ethernet: 8x 10G via 2x RTL8264 PHY
LEDs: 2 LEDs, 1 power green, 1 system green
Button: Reset
USB ports: None
Bootloader: Realtek U-Boot - U-Boot 2011.12.(3.6.6.55087) (Nov 13 2022 - 14:37:31)
Fan: 2 fans controlled by STC8G1K08 TSOP-20 microcontroller
PSE: 2x HS104
Note: The fan appears to operate the same irrespective of the running
firmware. The STC8G1K08 is likely operating independently.
To explore the stock vendor firmware, there are 2 avenues to gain root
access. This is not necessary to install OpenWrt, but is here for
reference.
Root access via serial
----------------------
1. ctrl+t
2. password: switchrtk
3. press 's' for shell
Root access via SSH
-------------------
1. ctrl+t
2. password: switchrtk
3. sys command sh
4. log in with your username+password
5. ctrl+t
6. password: switchrtk
7. press 's' for shell
Credit to https://forum.openwrt.org/t/hasivo-switches/151758/174 for rooting instructions.
Installing OpenWrt
------------------
1. Connect to UART. UART requires soldering an RJ45 connector to the
console footprint on the board. The header is on the top right of
this image: https://forum.openwrt.org/uploads/default/original/3X/4/d/4d2ab97fad7e2c5b0a0bdca4de887918c6dcff97.jpeg
2. Set computer IP to 192.168.0.111.
3. Enter bootloader by pressing esc key during boot.
4. Enter password 'Hs2021cfgmg'.
5. Type 'XXXX'.
6. setenv bootcmd 'rtk network on; bootm 0xb4300000'
7. saveenv
8. rtk network on
9. tftpboot 0x84f00000 <openwrt-initramfs>
10. bootm 0x84f00000
Now you can copy over the sysupgrade image and install.
Credit to
https://forum.openwrt.org/t/hasivo-switches/151758/22?u=andrewjlamarche
for u-boot console access instructions.
Andrew LaMarche [Tue, 21 Jul 2026 17:56:32 +0000 (17:56 +0000)]
realtek: rtl9303: split Hasivo S1100W(P)-8XGT-SE
Hasivo has two RJ45-only 8-port 10G switches, S1100W-8XGT-SE (non-PoE)
and S1100WP-8XGT-SE (PoE). The boards are both identical, with the
exception that the S1100WP-8XGT-SE has 2x HS104 PoE chips.
Make a shared dtsi to share between both variants.
bcm53xx: fix PCIe probe by using the hardware outbound window
Since the PCIe controllers gained a full DT description (349/350, commit 24ce1491cc37) every controller fails to probe with -EBUSY, and the window
it describes is at the wrong address on most boards.
devm_pci_alloc_host_bridge() parses the DT ranges and requests them, then
pcie-iproc-bcma adds its own window and requests the whole list a second
time, so that second request collides.
The outbound window base is fixed per PCIe core revision. Revision 0x01
uses 0x08000000, 0x40000000 and 0x48000000 for controllers 0 to 2, while
revision 0x07 uses 0x08000000, 0x20000000 and 0x28000000. Broadcom's own
driver branches on the core revision for this reason. 349 carries the
revision 0x07 values, so on revision 0x01 controller 1 points at an
address the hardware does not decode and the first BAR access aborts.
A .dtsi shared by every Northstar SoC cannot express a per-revision
value, but the enumeration ROM reports the right one and bcma already
provides it. Discard any memory window that came from the device tree and
use that instead, requesting only the window this driver owns. The driver
is then correct whether or not the DT describes a window.
Tested on an ASUS RT-N18U (BCM47081) and a Linksys EA9200 (BCM4709), both
core revision 0x01, on kernel 6.18.
qualcommax: qca-edma: support the kernel 6.18 threaded NAPI API
dev_set_threaded() takes an enum netdev_napi_threaded on 6.18; it was a
bool before. Select the argument on LINUX_VERSION_CODE so the driver keeps
building on the 6.12 main kernel and on the 6.18 testing kernel.
Without this, the 6.18 testing-kernel build fails with
-Werror=enum-conversion on the threaded-NAPI enable added in commit 98108710b6 ("qualcommax: qca-edma: enable threaded NAPI by default").
The patch reverted ath10k/ath11k to iommu_domain_alloc(), which kernel
6.18 removed; iommu_paging_domain_alloc() exists on every kernel this
tree builds. Unnoticed upstream because no 6.18 target builds
ath11k-ahb.
Enable linux 6.18 as the testing kernel; 6.12 stays the main kernel. The
config was created from config-6.12 and refreshed (defaults accepted for
new symbols; QCOM_PPE and PCS_QCOM_IPQ9574 - upstream's IPQ9574-generation
PPE/PCS drivers - stay disabled, this target uses its own EDMA/PPE/UNIPHY-PCS
drivers).
EC_HUAWEI_GAOKUN, EC_LENOVO_THINKPAD_T14S, VIDEO_QCOM_IRIS and QCOMTEE are
new ARCH_QCOM-gated symbols that are only visible in ALL_KMODS builds; answer
them explicitly so syncconfig stays non-interactive. QCOMTEE sits inside the
TEE menu, so it only became reachable once kmod-tee turned CONFIG_TEE on
(0f256a0a7adf "kernel: modules: package OP-TEE and fTPM modules").
qualcommax: dwmac-ipq5018: support the kernel 6.18 stmmac API
The fix_mac_speed() callback takes the speed as an int on 6.18
(SPEED_UNKNOWN is negative); it was unsigned int on 6.12. Select the
prototype on LINUX_VERSION_CODE so the driver keeps building on the 6.12
main kernel and on the 6.18 testing kernel.
qualcommax: pcs: qca-uniphy: support the kernel 6.18 phylink PCS API
pcs_get_state() gained a neg_mode parameter in 6.18, and the phylink_pcs
neg_mode opt-in field was removed (neg_mode is always passed now). Guard
both on LINUX_VERSION_CODE so the driver keeps building on the 6.12 main
kernel and on the 6.18 testing kernel.
Refresh the remaining patches against 6.18. Most only needed new line
offsets. Seven needed real porting because the code they touch changed
upstream:
- 0113, 0114, 0188, 0805, 0808, 0812: qcom_mdt_load_no_init() no longer
takes a pas_id argument, and qcom_mdt_load_no_init()'s MPD variant in
0812 swaps its pas_init/dma_require/pas_id parameters. 0805 also moves
from the removed platform_driver .remove_new to .remove.
- 0901 (Qualcomm CPR regulators): 6.18 added a cmp_int() macro to
linux/sort.h that collides with the driver's local comparator, which is
renamed cpr3_cmp_int().
Drop the 34 patches carrying a v6.13..v6.18 version prefix - all part
of kernel 6.18 - and three more whose content reached 6.18 through a
different route:
- 0111 (PCIe msi-parent): superseded, the ipq8074 PCIe nodes use split
msi0..msi7 interrupts upstream now.
- 0760 (Aquantia USXGMII MAC autoneg): generic/715 enables the same
autoneg bit unconditionally at config_init on 6.18.
- 0843 (stmmac get_interfaces): merged upstream.
The patches for later kernel versions are not in 6.18 and stay.
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
Florian Maurer [Mon, 29 Dec 2025 00:30:27 +0000 (01:30 +0100)]
package: utils: umbim: add dns servers independent of peerdns
This is required to add available dns servers in ifstatus output,
required by downstream tools to receive information of the configured
DNS server on the wwan interface.
This has no effect on the dns server selection, as peerdns has the
desired effect within netifd.
Florian Maurer [Mon, 29 Dec 2025 00:30:03 +0000 (01:30 +0100)]
package: utils: uqmi: add dns servers independent of peerdns
This is required to add available dns servers in ifstatus output,
required by downstream tools to receive information of the configured
DNS server on the wwan interface.
This has no effect on the dns server selection, as peerdns has the
desired effect within netifd.
Bogdan K [Wed, 22 Jul 2026 13:04:42 +0000 (16:04 +0300)]
uboot-mediatek: fix BT-R320 Ethernet mode
The CPU port between the MT7981 and MT7531 runs at 2.5 Gbps, but the U-Boot
device tree configures it as SGMII at 1 Gbps. This leaves Ethernet unable
to exchange packets despite an active physical link.
Use 2500base-x and a 2500 Mbps fixed link, matching the Linux device tree.
Fixes: a3105d3f9573 ("mediatek: filogic: add support for Globitel BT-R320") Signed-off-by: Bogdan K <zikwarface134@gmail.com> Link: https://github.com/openwrt/openwrt/pull/24372 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Upstream prefers fwnode helpers instead of OF ones (already done). This is
important for software nodes, which upstream is migrating to for its non
OF devices.
Shiji Yang [Sat, 25 Jul 2026 02:53:03 +0000 (10:53 +0800)]
editor: vscode: do not trim diff file trailing whitespace
This rule will break the patch structure.
Fixes: af75e1c527d0 ("vscode: update editor formatting and line endings settings") Signed-off-by: Shiji Yang <yangshiji66@outlook.com> Link: https://github.com/openwrt/openwrt/pull/24411 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
qualcommbe: dts: disable the driverless QCE crypto nodes
Commit ce120be361 ("kernel: disable qualcomm crypto") dropped the
CRYPTO_DEV_QCE kernel configs, so crypto@73a000 and its BAM no longer
have a driver. Unlike ipq8074, mainline ipq9574.dtsi ships both nodes
enabled by default, and gcc-ipq9574 registers its interconnect provider
with icc_sync_state; an enabled consumer that can never probe defers
that callback forever, so every boot logs
sync_state() pending due to 73a000.crypto
and the interconnect bandwidth votes are never allowed to drop from
their boot-time maximum. Disable both nodes explicitly in the board
device tree.
ipq40xx: dts: stop enabling the driverless QCE crypto nodes
Commit ce120be361 ("kernel: disable qualcomm crypto") dropped the
CRYPTO_DEV_QCE kernel configs, so crypto@8e3a000 and its BAM no longer
have a driver. The board device trees still override both nodes to
"okay" (two boards also carry BAM channel properties that only exist
to serve the crypto engine), leaving enabled consumers that can never
probe. Drop the overrides and fall back to the SoC dtsi defaults, which
ship both nodes disabled.
Unlike ipq807x, no supplier on ipq4019 registers a sync_state()
callback, so the stale overrides are only dead code here.
qualcommax: dts: stop enabling the driverless QCE crypto nodes
Commit ce120be361 ("kernel: disable qualcomm crypto") dropped the
CRYPTO_DEV_QCE kernel configs, so crypto@73a000 and its BAM no longer
have a driver. The board device trees still override both nodes to
"okay", which leaves an enabled consumer that can never probe. On
ipq807x the GCC clock controller registers the USB GDSC power domains,
the genpd core therefore installs a sync_state() callback on it, and
fw_devlink then defers that callback forever, logging
qcom,gcc-ipq8074 1800000.clock-controller: sync_state() pending due to 73a000.crypto
on every boot and keeping unused power domains from being released.
Drop the overrides and fall back to the SoC dtsi defaults. On ipq8074
mainline ships both nodes disabled and no mainline board enables them;
on ipq5018/ipq6018 they are enabled by default, but the GCC drivers
there register no power domains, so no sync_state() dependency exists.
Daniel Golle [Sat, 25 Jul 2026 16:29:57 +0000 (17:29 +0100)]
fstools: update to git HEAD of 2026-07-25
2aa1640 block: preen a registered volume before mount on request d43ffba block: use preen mode for the f2fs filesystem check a71e97d blockd: do not let a slow startup helper hold back readiness 1c17d24 blockd: expose storage readiness via a queryable status method f60b3a3 blockd: pass registrant mount options down to block on autofs mount 998f6ab blockd: notify when an idle autofs mount is unmounted 0008996 block: mount ubus-registered devices without an fstab entry 4fd1502 blockd: coldplug block devices 89a6f52 blockd: retry interrupted waitpid() in synchronous block() helper 37cf94d blockd: fix bounds of the ubus event name buffer
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Josef Schlehofer [Thu, 23 Jul 2026 09:27:39 +0000 (11:27 +0200)]
github: switch issue-labeller to bot webhook and add configuration
Remove the standalone GitHub Actions issue-labeller.yml workflow in favor
of the webhook-based openwrt-bot worker.
Enable issue labeller in formalities.json and add a declarative
.github/issue-labeller.yml configuration file for automated validation
and labelling of bug reports (release, target, image kind, device).
The release rule lists two alternative conditions under a single label
key: concrete releases (x.y.z, x.y.z-rcN) are validated against their
Git tag via exists check, while stable-branch snapshots (x.y-SNAPSHOT)
are format-validated only — OpenWrt does not tag snapshot builds.
realtek: eth: reclaim completed TX buffers on RX poll
The transmit path frees a TX skb only when its descriptor slot is
reused, RTETH_TX_RING_SIZE transmissions later. Until then the skb
stays charged to the sending socket's send buffer. With standard
frames the pinned amount is negligible, but with jumbo frames a
handful of completed transmissions is enough to exhaust the sender's
budget: eight ~9k echo replies exceed the kernel ICMP socket limit of
2 * SKB_TRUESIZE(64 * 1024), after which the stack drops every further
reply of any size (Icmp OutErrors) until unrelated transmissions
happen to recycle the slots. Observed on the Hasivo S1100W-8XGT-SE
(RTL9303) as a total ICMP blackout setting in after exactly eight
jumbo echo replies, healed by any sixteen device-originated frames.
Track monotonic send/clean counters in the driver-private ring info
(their difference is the number of unreleased skbs, their low bits the
ring slots), and release the contiguous completed run at the start of
the RX poll, before the received packets are processed, so replies
generated while handling the poll always find their send budget
released. The walk runs under the TX queue lock the
transmit path already holds, stops at the first descriptor the
hardware still owns, and is skipped entirely - no lock taken, no
access to the uncached descriptor memory - while nothing is pending.
The transmit path reuses the same walk for the ring-wrap case instead
of its old per-slot cleanup, and stopped or watchdog-frozen queues
are left to the rteth_tx_timeout() recovery, which keeps releasing
every buffer itself.
The GS1900-24E B1 is a different hardware revision, not merely a
front-panel relabel as suggested by Zyxel's user guide. Verified
differences vs. A1 (sources: TechInfoDepot for A1 spec data,
https://techinfodepot.shoutwiki.com/wiki/ZyXEL_GS1900-24E):
* PCB: 37ZY-GM2430+212 V1.2 (A1: 37ZY-G724DO+412 V.12)
- different board part number, not a stepping of the same one
* RAM: 128 MiB DDR3, A1: 128 MiB DDR2
* Flash: mx25l12805d, 16 MiB (A1: 16 MiB SPI-NOR)
* External PHYs: RTL8218D (A1: unknown)
* Rear power switch: absent on this B1 unit (inlet only). A1 is
described as having one in the *title* of openwrt/openwrt#18620,
but that issue does not explicitly identify the affected hardware
as "A1" specifically, nor is it confirmed by a spec sheet or photo
* ZYXEL_VERS firmware family unchanged (AAHK)
The existing MDIO bus addressing and switch-port SerDes layout
from -a1.dts work unmodified on B1, since the PHY driver
identifies the external chip by ID registers at runtime rather
than from DT compatible string, regardless of what chip A1
actually uses.
Deliberately omits the gpio0 mdio-reset gpio-hog present in
-a1.dts (ba57225066, #18620) pending confirmation it's needed on
B1's differing reset-line topology. Tagged 802.1Q VLAN traffic
tested clean across software reboot and full AC power-cycle, on
both kernel 6.6/24.10.5 and current master (6.18), with no sign
of the #18620 stuck-RX regression.
Encapsulates the two external RTL8218D PHY packages per the tree-wide
ethernet-phy-package conversion for RTL8218x chips; ports 8-15 use the
SoC-integrated PHY block and aren't part of an external package.
realtek: remove stray PoE budget entries for GS1900-8HP A1/B1
Commits ab649f19ab and 64315f29c4 moved the GS1900-8HP B1 and A1 to the
in-kernel PSE MCU driver, but overlooked the /etc/board.d/02_network
PoE budget entries. Remove them.
Fixes: ab649f19ab realtek: use Realtek PSE MCU driver for GS1900-8HP B1 Fixes: 64315f29c4 realtek: use Realtek PSE MCU driver for GS1900-8HP A1 Signed-off-by: Stijn Segers <foss@volatilesystems.org> Link: https://github.com/openwrt/openwrt/pull/24380 Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Ahmed Naseef [Mon, 6 Apr 2026 10:19:15 +0000 (14:19 +0400)]
mediatek: add support for Airtel AirFiber AAP4221ZY
The Airtel AirFiber AAP4221ZY is an ISP-provided router that is part
of the ISP's Fixed Wireless Access (FWA) solution. The FWA system
consists of two units: an outdoor 5G unit and this indoor Wi-Fi router
connected via a PoE ethernet link. This commit adds support for the
indoor unit.
The OEM appears to be Zyxel with model number EX3310-T0, although this
is not printed on any label and only found in the vendor firmware DTS,
bootlog, and other internal references.
Bootloader
----------
The device uses BL2 -> U-Boot -> Zyxel zloader chain. U-Boot has a
hardcoded command to always launch zloader (similar to the Zyxel
EX5601-T0, see commit 1c05388ab04c). zloader is the Zyxel secondary
bootloader which handles dual-boot (ubi/ubi2 A/B scheme), firmware
verification, and PoE port enablement.
zloader requires a UBI volume named "zyfwinfo" containing a 256-byte
metadata structure with a "ZYXE" magic header and a valid checksum.
Without this volume, zloader refuses to boot the firmware. The
zyfwinfo structure also contains a sequence number (range 0-9999,
wraps around) used to select which firmware bank to boot - the bank
with the higher sequence number wins. This OpenWrt image sets it to
5555 to always win over stock firmware starting at 0.
During sysupgrade, platform.sh refreshes the zyfwinfo volume before
writing kernel and rootfs to UBI, as rootfs_data is sized to fill the
remaining space.
Note that OpenWrt can only be flashed to ubi (mtd6). The zloader
appends rootubi=ubi or rootubi=ubi2 to the kernel bootargs based on
which partition it selects, but OpenWrt cannot understand this
parameter, so the firmware must always reside on the first bank (ubi).
UART access
-----------
Serial console output is restricted by the U-Boot environment variable
EngDebugFlag which is 0x00 by default. Users need to first obtain root
access on the vendor firmware and run:
fw_setenv EngDebugFlag 0x01
Then reboot. Connect UART and press Enter to enter the zloader shell
(ZHAL> prompt). Use the ATGU command to switch to the U-Boot shell.
Note: ATGU must be entered twice to get the MT7981> prompt:
ZHAL> ATGU
[zloader reloads]
ZHAL> ATGU
MT7981>
Installation
------------
1. Enable UART access as described above.
2. Enter U-Boot shell (ATGU twice from ZHAL> prompt).
3. Load the initramfs image via TFTP:
The RTL8367S SerDes can be muxed to external interface 1 (typically
the CPU port). SGMII/HSGMII were already listed as supported modes
in the chip info table, but only RGMII was implemented. This adds a
phylink PCS for the SerDes, with the configuration derived from the
GPL-licensed Realtek rtl8367c vendor driver.
Tested on a Mercusys MR80X v2.20 (RTL8367S over HSGMII).
realtek: dts: declare RTL8264 SerDes lane polarity on Hasivo S1100W-8XGT-SE
The rtl826x PHY driver programs the system-side SerDes lane polarity of
the RTL8264 from the "rx-polarity"/"tx-polarity" devicetree properties,
defaulting to normal polarity when they are absent. The Hasivo
S1100W-8XGT-SE routes half of its high-speed lanes with inverted
polarity, which the vendor bootloader compensates for by setting
HSI_INV/HSO_INV (VEND1 0xC1 bits 6/7) per PHY. Without the properties
the driver clears those bits on every PHY (re-)initialization, which
kills the USXGMII link of every port: egress frames never reach the
wire while the port MAC MIB keeps counting them, and ingress dies with
it (issue #24359 for this board).
Declare the polarity for all eight PHYs, matching the values the
bootloader programs (read back on hardware in the U-Boot state:
alternating HSO_INV/HSI_INV per port pair). The already-supported
S1300WP declares these properties the same way.
Verified on hardware: on a pristine build both traffic directions are
dead; with only this devicetree change, ingress runs at full rate,
egress passes traffic, and the link now survives netifd restarts and
renegotiation. 10GBase-T ports also negotiate 10G instead of falling
back to 5G.
realtek: mdio: Add polling configuration for RTL8264
RTL8264 polling is not configured until now. Boot log gives
"skip polling setup for phy 0x001ccaf2 on port xx". Add the
PHY features to rtmd_get_phy_info().
Paul Spooren [Thu, 23 Jul 2026 12:39:19 +0000 (14:39 +0200)]
build: make GL.iNet metadata reproducible
The GL.iNet specific metadata contains a `date`-field which takes the current
timestamp instead of using SOURCE_DATE_EPOCH. This commits make use of the
variable, if available.
Paul Spooren [Wed, 22 Jul 2026 12:37:12 +0000 (14:37 +0200)]
toolchain: drop $(REVISION) from GCC version
Storing the ever changing revision in the GCC binary may result in leakage in
package builds. If two equal GCC versions build the same package version with
different OpenWrt revisions, the package becomes unreproducible.
Kyle Hendry [Thu, 7 May 2026 04:27:15 +0000 (21:27 -0700)]
bcm47xx: refresh 6.18 patches
- Manually rebase 830-huawei_e970_support.patch
- Update .remove_new to .remove in 831-old_gpio_wdt.patch, see
commit e70140ba0d2b1a30467d4af6bcfe761327b9ec95
- make target/linux/refresh the rest
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
Josef Schlehofer [Mon, 20 Jul 2026 11:39:33 +0000 (13:39 +0200)]
github: downgrade require_linked_github_account to warning
Some contributors still submit patches via the mailing list or are
not using GitHub entirely, so an unlinked commit author email
should not be treated as a hard failure.
The CPU thermal zone in an7583.dtsi sets the polling-delay-passive to
10000 ms while the polling-delay is 5000 ms. The thermal driver rejects
zones whose passive polling delay is greater than the regular polling
delay, causing thermal_zone0 registration to fail with -EINVAL.
Reduce the passive polling delay to 1000 ms to fix thermal_zone0
registration.
Boot log:
thermal_sys: Failed to register thermal zone cpu-thermal: -22
... register thermal zone sensor failed
... probe with driver airoha-thermal failed with error -22
The ChinaMobile GS3101 has:
256MB RAM
256MB flash (TC58CVG1S3H)
1x MT7603 802.11 b/g/n - DISABLED
1x optical port
On-die MT7530 switch with:
- 1x gigabit ethernet port
- 3x 100Mb ethernet ports
1x USB 2.0 port
1x telephone VoIP port
3 controllable LEDs
1 GPIO button (reset), 1 WPS button (not detected in GPIOs)
UART header inside (solder required) 115200 baud
12v power (5.5mm x 2.1mm barrel connector)
Installation instructions: You will need a USB stick
1. Reformat the USB stick as VFAT with MBR partition table. This is important,
if it is GPT then it will silently fail to load.
2. Download openwrt-econet-en751221-chinamobile_gs3101-squashfs-tclinux.trx and
store it in the USB stick.
3. Start the device with the vendor OS
4. Connect a cable and request an IP address - it will issue in 192.168.1.0/24
5. Use telnet to connect to the modem on 192.168.1.1
6. Login as root@2024 / system
7. Plugin the USB stick
8. cp /mnt/usb1_1/openwrt-econet-en751221-chinamobile_gs3101-squashfs-tclinux.trx /tmp/openwrt.trx
9. mtd -r -f write /tmp/openwrt.trx tclinux
10. You will lose your shell, look at the power light on the device, it should
begin blinking and then go back to solid. You should NOT see any red light.
11. re-request an IP address
12. ssh root@192.168.1.1
13. You should be on OpenWrt now
MAC address matches that of vendor OS but it is not the address on the label
of the device. It is in a compressed xml file in the 'romfile' partition.
WAN is this mac, LAN is mac+1 and 2.4Ghz WLAN is mac+2, there is no 5Ghz WLAN.
Wifi Note: Of the devices tested, there were numerous upon which starting the
wlan chip caused the CPU to hang. In the interest of avoiding bricked boards,
the wlan is disabled in the DT.
econet: tclinux-trx.sh make rootfs optional and move padding to kernel
The TRX header contains a checksum of the full kernel and rootfs length. Vendor
OS uses a raw squashfs on the NAND and relies on the BMT to resolve bad block
issues. OpenWrt typically uses UBI on NAND and places the root squashfs inside
of that. Since UBI changes over time, checksumming over it would cause a boot
failure later on. However, vendor TRX installers typically the entire file as
uploaded, without regard for the declared kernel and rootfs lengths.
Make --rootfs optional so that a UBI rootfs can be appended but excluded from
the checksum.
Secondly, this script previously prepended padding to the rootfs in order to
move the beginning of the rootfs 4MB away from the TRX header (the max kernel
size). That prepended padding was included in the rootfs length/checksum.
There is a bug https://econet-linux.pkt.wiki/en/bootloader#a-length-bug in some
versions of the bootloader which causes the bootloader to always use the length
of the first kernel, even if it is booting the second. The impact of this is if
the second slot kernel is larger than the first, it will fail to boot. Smaller
is okay because LZMA will stop when it is done.
Move padding from rootfs to kernel and include it in the length/checksum of the
kernel so that the kernel will always register as being 4MB-minus-TRX-header in
length. Therefore if A/B upgrading is used in the future, this bug will not
occur even if an upgrade with a larger kernel is installed into slot B.
Some issues were noticed with watchdog driver while the work
on bringing regmap API was being done.
The patches have been long accepted and are already in v7.2
of linux kernel.
As a prerequisite to the regmap patch, backport them to OpenWrt.
Felix Fietkau [Wed, 22 Jul 2026 07:20:48 +0000 (09:20 +0200)]
wifi-scripts: support multiple device paths per board.json wlan entry
The path field of a board.json wlan entry may now be an array of
device paths. ucidef_add_wlan accepts several leading path arguments
and stores them as a JSON array; a single path is still stored as a
plain string for backwards compatibility. A phy is matched if it
corresponds to any of the listed paths, so a radio that enumerates on
a non-deterministic PCI path still resolves to the correct named phy.
Since the jumbo frame preparation the driver can work on fragments
and not only on complete packets in the receive path. This might be
implementet in the transmit patch in the future too. So a chunk of
data is best described as a fragment. Rename all occurrences.
realtek: eth: change skb helper function signatures
It is easier to work with ring/slot when shifting around variables
in the different structures. Replace packet pointers in existing
function signatures.
projects / thirdparty / openwrt.git / log
