John Thomson [Sun, 5 Oct 2025 03:45:41 +0000 (13:45 +1000)]
ipq40xx: mikrotik: kernel: pet watchdog during kernel uncompress
kernel 6.9 removed the KConfig entry our RouterBOOT watchdog pet hack was relying on:
Linux df59427a1122 ("ARM: qcom: merge remaining subplatforms into sensible Kconfig entry")
Introduce a new specific KConfig entry for this hack,
and enable it for Mikrotik ipq40xx kernel.
CONFIG_ARCH_QCOM_IPQ40XX_BOOT_COMPRESSED_PET_WATCHDOG_EARLY
With appropriate DEBUG_LL and DEBUG_UNCOMPRESS, this watchdog reset
can be typically seen on console as a reset before "Uncompressing Linux..."
reaches " done, booting the kernel."
RouterBOOT
loading kernel... OK
setting up elf image... OK
jumping to kernel code
Jumping to kernel
DTB:0x80381A60 (0x000048C4)
C:0x800000E0-0x80386420->0x80FAB500-0x81331840
DTB:0x8132CE80 (0x000049B8)
Uncompressing Linux...
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.1.1-00096
versus:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
On Mikrotik RouterBOOT devices, this is complicated by some RouterBOOT
versions successfully loading the same kernel that other RouterBOOT versions fail. Example:
RouterBOOT backup booter 6.45.9 fine, RouterBOOT booter 7.16 fail
Fixes: openwrt#19841 Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au> Link: https://github.com/openwrt/openwrt/pull/20305 Signed-off-by: Robert Marko <robimarko@gmail.com>
Kenneth Kasilag [Fri, 17 Oct 2025 02:07:25 +0000 (02:07 +0000)]
kernel: rtl8261n: allow selection as package
Previously, devices would have to select `CONFIG_RTL8261N_PHY=Y` in the
whole target's kernel config. Now that this driver is becoming usable
for devices other than Realtek switches, allow packaging this driver
separately.
Magnus Kroken [Thu, 16 Oct 2025 14:11:11 +0000 (16:11 +0200)]
mbedtls: update to 3.6.5
This release includes fixes for security issues.
Mbed TLS 3.6 is a long-term support (LTS) branch. It will be supported
with bug-fixes and security fixes until at least March 2027.
The two issues fixed were timing side channels:
* Padding oracle through timing of cipher error reporting
(CVE-2025-59438) [1]
* Side channel in RSA key generation and operations (SSBleed, M-Step)
(CVE-2025-54764) [2]
Bug fixes:
* Fix potential CMake parallel build failure when building both the static and shared libraries.
* Fix a build error or incorrect TLS session lifetime on platforms where mbedtls_time_t is not time_t.
Hauke Mehrtens [Mon, 13 Oct 2025 22:32:26 +0000 (00:32 +0200)]
ltq-ptm: Fix unprivileged local user memory read and write
Use the copy_from_user() and copy_to_user() functions for accessing
memory provided by the user in the ptm netdev iotls.
In addition also check for root permission before executing ioctl.
Suggested-by: Stanislav Fort from Aisle Research Reported-by: Stanislav Fort from Aisle Research Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Felix Fietkau [Fri, 17 Oct 2025 11:28:52 +0000 (13:28 +0200)]
ubus: update to Git HEAD (2025-10-17)
b462895d3157 lua: CMakeLists: drop redundant cmake_minimum_required f247c18f8a55 examples: CMakeLists: drop redundant cmake_minimum_required 83a70399030d github: add CI build d31effb4277b ubusd: Fix out of bounds access in event register message d95837b1b143 ubusd: acl: compare uid/gid instead of user/group strings b81257bb20dd ubusd: load extra group IDs for a client process 7d7b45fea05b add debian/ directory aa4a7ee1d341 ubusd: fix more instances of missing length checks for patterns 60e04048a0e2 ubusd: fix ACL check for receiving events
Eric Fahlgren [Wed, 8 Oct 2025 16:42:21 +0000 (09:42 -0700)]
targetwide: imagebuilder: add explicit guards around initramfs rules
The imagebuilder is not intended to build initramfs images. Some
profiles attempt to do this and succeed, due to buildroot leaking
the initramfs-kernel into staging_dir; others attempt it, but fail
due to not having initramfs binaries present in the imagebuilder.
Fix this by adding an explict guard around the unsupported generation
of the initramfs images. This saves space and time during imagebuilder
runs, fixes those that are currently broken and protects against future
breakage for profiles that inadvertently work now.
Fixes: https://github.com/openwrt/openwrt/issues/20151 Signed-off-by: Eric Fahlgren <ericfahlgren@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20347 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Thu, 16 Oct 2025 09:06:08 +0000 (11:06 +0200)]
realtek: dsa: rtl931x: Fix port L2 table flushing
The DSA driver must flush the HW FDB when a port changes from
learning/forwarding to disabled/blocking/listening.
But the implementation for RTL931x was writing the port information
starting at bit 11 (bit 11 of the second 32-bit L2_TBL_FLUSH_CTRL
register). But this offset is the AGG_VID and not the port. The actual
position is 43 (bit 11 of the first register).
As result, the FDB was always only flushed for the port 0 and not for the
selected port.
Fixes: 9ed609705481 ("realtek: Add HW support for RTL931X for PIE, L2 and STP aging") Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20422 Signed-off-by: Robert Marko <robimarko@gmail.com>
Andrew Sim [Mon, 6 Oct 2025 04:58:44 +0000 (06:58 +0200)]
mediatek: filogic: rename eth1 to wan in led setup for zyxel-ex5601-t0
the eth1 interface was renamed to wan so also reflect that change in
the leds setup script
Fixes: f26260c7e751 ("mediatek: filogic: Add label wan and cpu for Zyxel EX5601-T0") Signed-off-by: Andrew Sim <andrewsimz@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20120 Signed-off-by: Nick Hainke <vincent@systemli.org>
Harshal Gohel [Fri, 8 Aug 2025 15:31:03 +0000 (17:31 +0200)]
realtek: rtl93xx: Trap BPDU management frames
BPDU frames like STP must be processed by each switch (bridge) which
supports STP. It must not be forwarded to avoid confusing the STP state of
other STP participants. It is essential to be an active participant of STP.
The software bridge automatically takes care of forwarding the BPDUs to
other ports when STP is disabled and the hardware switch should not
interfere.
Signed-off-by: Harshal Gohel <hg@simonwunderlich.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20414 Signed-off-by: Robert Marko <robimarko@gmail.com>
ksmbd.mount will give each interfaces list and bind_interfaces_only flags
to ksmbd server. Previously, the interfaces list was sent only
when bind_interfaces_only was enabled.
ksmbd server browse only interfaces list given from ksmbd.conf on
FSCTL_QUERY_INTERFACE_INFO IOCTL.
I've experienced the LAN port failing to initialize from a cold boot and
after a reboot. Other users have reported this issue on
https://forum.openwrt.org/t/nanopi-r4s-rk3399-is-a-great-new-openwrt-device/79143.
The NanoPI R4S has its LAN port connected to the RK3399 via PCIE. Since the
PCIE lanes don't initialize correctly after reboot, the LAN port
doesn't initialize.
Christoph Krapp [Thu, 25 Sep 2025 07:30:27 +0000 (09:30 +0200)]
ath79: add calibtation variant for TP-Link Archer C59 v1
Now that we have a board file, add calibration variant for TP-Link
Archer C59 v1 and add ipq-wifi package for it.
Tested-by: Mateusz Jończyk <matjon@users.noreply.github.com> Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/20401 Signed-off-by: Robert Marko <robimarko@gmail.com>
apk-tools: fix compilation warning from downstream full print patch
Fix trivial compilation warning caused by downstream full print patch.
../src/app_list.c: In function 'print_full':
../src/app_list.c:85:35: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=]
85 | printf("Installed-Size: %zu\n", pkg->installed_size);
| ~~^ ~~~~~~~~~~~~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| unsigned int
| %llu
../src/app_list.c:86:25: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'uint64_t' {aka 'long long unsigned int'} [-Wformat=]
86 | printf("Size: %zu\n", pkg->size);
| ~~^ ~~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| unsigned int
| %llu
../src/app_list.c:58:31: warning: unused variable 'd' [-Wunused-variable]
58 | struct apk_dependency d;
Remove unused variable and use PRIu64 to handle uint64_t type.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
tools/meson: add pending patch to improve binary reproducibility
Add 3 pending patch that improve binary reproducibility. The first
address a problem with RPATH string not getting cleared on removal of
RPATH entry from ELF section. The other 2 skip including external shared
library in RPATH in meson build phase.
This follows the logic that on cross-compiling we can't run the binary
anyway as it does target a different arch hence it doesn't make sense to
include those extra path in RPATH causing reproducibility problems (as
path for those external library will depend on the build system path)
George Moussalem [Tue, 14 Oct 2025 09:36:17 +0000 (13:36 +0400)]
qualcommax: ipq50xx: fix XO board clock rate for Yuncore AX850
Commit 468975a985ab changed the XO board clock definition from a fixed
clock to a fixed rate clock in the dtsi.
As such, boards must use clock dividers and multipliers to calculate
the clock rate based on the referenced parent clock.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://github.com/openwrt/openwrt/pull/20405 Signed-off-by: Robert Marko <robimarko@gmail.com>
Add pending patch to address PCI sysfs creation entry race observed on
ipq806x. This is to handle a kernel warning on creating the same sysfs
entry multiple times.
Shiji Yang [Wed, 18 Jun 2025 11:50:39 +0000 (19:50 +0800)]
ipq806x: migrate wifi configuration device paths for 6.12 kernel
The device tree PCIe host node names have been changed in the new
6.12 kernel[1]. Hence we have to update the wifi device path to
make sure it can work properly.
This script is based on:
target/linux/qualcommax/ipq807x/base-files/etc/hotplug.d/ieee80211/05-wifi-migrate
These devices' reg cell[0] is equal to 0x10000, hence the correct
node unitname should be "0,0". This patch fixes the following dtc
warnings on 6.12 kernel:
qcom-ipq8065-tr4400-v2.dts:482.11-487.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-tr4400-v2.dts:499.11-504.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-rt4230w-rev6.dts:584.11-589.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-rt4230w-rev6.dts:601.11-606.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-g10.dts:291.11-295.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-g10.dts:303.11-307.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wxr-2533dhp.dts:525.11-530.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wxr-2533dhp.dts:539.11-544.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ecw5410.dts:235.11-239.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ecw5410.dts:251.11-255.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ap3935.dts:261.11-264.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-ap3935.dts:275.11-278.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-fap-421e.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-fap-421e.dts:362.11-367.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:78.18-81.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:89.18-92.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8068-cryptid-common.dtsi:100.18-103.4: Warning (pci_device_reg): /soc/pcie@1b900000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wg2600hp.dts:464.11-469.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-wg2600hp.dts:478.11-483.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8062-wg2600hp3.dts:404.11-410.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8062-wg2600hp3.dts:419.11-426.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-d7800.dts:210.11-215.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-d7800.dts:227.11-232.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-r7500v2.dts:213.11-218.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-r7500v2.dts:230.11-235.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-nighthawk.dtsi:546.18-549.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-nighthawk.dtsi:559.18-562.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-ac400i.dts:202.11-206.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8065-ac400i.dts:218.11-222.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-ad7200-c2600.dtsi:319.11-324.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-ad7200-c2600.dtsi:333.11-338.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-vr2600v.dts:347.11-352.4: Warning (pci_device_reg): /soc/pcie@1b500000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
qcom-ipq8064-vr2600v.dts:361.11-366.4: Warning (pci_device_reg): /soc/pcie@1b700000/pcie@0/wifi@1,0: PCI unit address format error, expected "0,0"
Shiji Yang [Sun, 1 Jun 2025 04:56:09 +0000 (12:56 +0800)]
ipq806x: dts: rework PCIe nodes for Chromium OnHub
- Reuse the bridges node defined on "qcom-ipq8064.dtsi".
- Rename PCIe device nodes to unified "wifi@0,0".
- Add the missing "qcom,ath10k" compatibles.
- Remove unseless property "interrupt-controller". There are no
consumers use these PCIe devices as interrupt controllers.
- Change bus number from 0 to 1, just like other ipq806x devices.
The valid PCIe bus range on this platform is 1 - 255.
Shiji Yang [Sat, 31 May 2025 16:41:31 +0000 (00:41 +0800)]
ipq806x: fix build errors on 6.12 kernel
- Replace "strlcpy()" with "strscpy()".
- Convert platform driver .remove() to .remove_new().
This patch fixes the following compile errors:
drivers/of/fdt.c:1064:17: error: implicit declaration of function 'strlcpy'; did you mean 'strncpy'? [-Wimplicit-function-declaration]
1064 | strlcpy(cmdline, p, min((int)l, COMMAND_LINE_SIZE));
| ^~~~~~~
| strncpy
drivers/devfreq/krait-cache-devfreq.c:171:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types]
171 | .remove = krait_cache_remove,
| ^~~~~~~~~~~~~~~~~~
drivers/devfreq/ipq806x-fab-devfreq.c:145:27: error: initialization of 'void (*)(struct platform_device *)' from incompatible pointer type 'int (*)(struct platform_device *)' [-Wincompatible-pointer-types]
145 | .remove = ipq806x_fab_remove,
| ^~~~~~~~~~~~~~~~~~
Shiji Yang [Sat, 31 May 2025 15:09:58 +0000 (23:09 +0800)]
ipq806x: refresh kernel symbol configs
This is a preparation for introducing the 6.12 kernel support.
All configs are automatically refreshed. In theory, they will
generate the same .config files in the kernel build directory
as before.
sdk: set package as the root directory for base feed
To produce consistent source entry for package compiled from non-SDK and
SDK build, set the "--root=package" flag for the base feed.
This will set the root directory for the base feed to the OpenWrt
core repository "package" directory.
This fix the reproducible problem of package build from SDK that have
the source entry set to "feeds/base/package/..." for every package
coming from the base feed.
scripts/feeds: implement support for --root option
Some feeds might need to set the source for their packages in a
different directory than the cloned one.
For example a feed "test" might be an entire repository and the relevant
packages that wants to be included are in the directory "foo".
In such scenario the source info in the package will result in something
like "feeds/test/foo/network/dnsmasq" instead of an expected entry like
"feeds/test/network/dnsmasq".
To give a more real-world example, this problem is currently present
with OpenWrt SDK where the SDK clone the entire OpenWrt core repository
as "base" feeds but the package are present in the "package" directory.
This cause every package to have the source entry set to
"feeds/base/package/..." conflicting with what a non-SDK build do with
setting the source entry to "feeds/base/..."
To solve this, actually enable support for "flags" in the feeds script
and implement a new option "--root" to set the root directory for the
defined feed to an inner directory.
The "flags" in the feed script are no more than argument option that can
be defined right after the "src-" type in the feed.conf file.
This feature was partially implemented but never actually used for
anything keeping it dormant with all the core piece there (the pattern
regex always accounted for these extra option but they were never passed
to the relevant functions)
An example of the "--root" flag is the following:
src-git --root=package base https://git.openwrt.org/openwrt/openwrt.git;main
With "--root" defined, the script will append "_root" to the feed name
clone directory and will create a symbolic link named with the feed name
and pointing to the feed name clone directory + the value in root.
From the previous example:
feed name: base -> clone directory: base_root
symbolic link: base -> base_root/package
The script internally reference the "_root" directory for every update
operation and OpenWrt build system transparently use the feed name
directory to reference feed packages producing consistent source info
entry.
Zhi-Jun You [Wed, 8 Oct 2025 06:55:06 +0000 (14:55 +0800)]
wifi-scripts: ucode: fix airtime_mode with hostapd-mini
Currently wifi-scripts ucode appends airtime_mode to hostapd config file
unconditionally.
However this breaks bringing up interface with hostapd-mini
because the mini variant doesn't support airtime policy.
Fix this by changing the script to append airtime_mode only when
airtime_mode is set to greater than zero value in /etc/config/wireless.
Fixes: #20136 Fixes: #20314 Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Lorenz Brun [Fri, 10 Oct 2025 21:11:38 +0000 (23:11 +0200)]
realtek: fix SFP ports on RTL83xx
Right now the phylink capability function enables 2.5G and 10G modes on
Maple and Cypress, which they mostly (other than two SERDES on Cypress)
don't support. This causes these modes to be selected and break the link
as they are not supported by hardware.
I looked into doing this properly, but it cannot just be done based on
SoC, but needs to take the whole topology into account as a given MAC
might have very different capabilities depending on what SERDES are
assigned to it. So for now just use 1G and QSGMII for RTL83xx and 10G
for RTL93xx. This mostly works, except it will downgrade some 10G links
on RTL839x, but since there are also 1G SFPs on these this cannot be
solved without fully accounting for the global MAC and SERDES
configuration.
So this makes all of the 1G SFP slots work again, while keeping most of
the 10G SFP+ slots working at 10G with minimal changes.
Sven Eckelmann [Mon, 29 Sep 2025 16:30:12 +0000 (18:30 +0200)]
realtek: Skip auto-MAC assignment for devices with MACs in DT
If the devicetree contains the appropriate nodes to configure the MAC
addresses for each physical DSA port, then these MAC addresses must be used
in OpenWrt and not some automatically generated ones. Otherwise the device
often ends up with addresses which are locally administered and not
matching any expected port-to-MAC scheme.
Devices which only get the MAC address for eth0 must still auto-generate
these MAC addresses until the devicetree was updated to also include the
correct ones.
Sven Eckelmann [Sun, 5 Oct 2025 07:00:08 +0000 (09:00 +0200)]
realtek: Avoid empty lan mac in initial network setup
If the lan_mac cannot be found, it is still used (as empty string) in
various operations. This is not valid and other 02_network scripts checking
for a non-empty string before using it. This should also be adopted for the
realtek 02_network.
Sven Eckelmann [Sun, 5 Oct 2025 06:55:49 +0000 (08:55 +0200)]
realtek: Split initial network setup in functions
Having everything in a big script without any structure makes it
unnecessary hard to get an overview or modify it without triggering
unexpected side effects.
Sven Eckelmann [Fri, 10 Oct 2025 09:49:56 +0000 (11:49 +0200)]
realtek: dsa: Adjust prefix for bridge member functions
The preferred prefix for the Realtek DSA driver code is "rtldsa" and no
longer "rtl83xx". This makes sure that the different drivers have
non-conflicting prefixes and because of this non-conflicting function
names.
Suggested-by: Felix Baumann <felix.bau@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20360 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Fri, 10 Oct 2025 09:49:56 +0000 (11:49 +0200)]
realtek: dsa: Fix name of RTL93xx switch_ops
The RTL930x and the RTL931x SoC families share the same struct
dsa_switch_ops. This should be represented in the name of the object.
Suggested-by: Felix Baumann <felix.bau@gmx.de> Signed-off-by: Sven Eckelmann <se@simonwunderlich.de> Link: https://github.com/openwrt/openwrt/pull/20360 Signed-off-by: Robert Marko <robimarko@gmail.com>
Sven Eckelmann [Thu, 9 Oct 2025 12:59:16 +0000 (14:59 +0200)]
realtek: dsa: Add support for port isolation
If two ports are in isolation mode then these ports are not supposed to be
able to communicate between each other. This can be achieved in the realtek
switch by removing the other isolated port(s) from the port list of an
isolated port.
Sven Eckelmann [Thu, 9 Oct 2025 13:01:06 +0000 (15:01 +0200)]
realtek: dsa: Drop unused traffic_get helpers
The realtek driver is now in full control of the port matrix. It doesn't
need to rely on the current state of the HW to adjust it. The new port
matrix is calculated automatically using rtldsa_update_port_member() and
then written to the registers/tables.
Sven Eckelmann [Thu, 9 Oct 2025 14:28:47 +0000 (16:28 +0200)]
realtek: dsa: Simplify port member handling
It is not necessary to read the back the current port members for a
specific port for enabling/disabling a port. All these members which are
expected to be in the HW port matrix of an active port are already stored
in the port specific member "pm".
And when a port is disabled, the port must no longer forwarding traffic to
any other port. Just writing 0 to the members is therefore good enough and
no read-back of the old HW state is necessary.
Sven Eckelmann [Thu, 9 Oct 2025 12:56:39 +0000 (14:56 +0200)]
realtek: dsa: Share port member configuration code
The leave and join callbacks for DSA were using their own implementation of
the port member handling code. This makes the implementation of additional
functionality based on the port member matrix complicated because it needs
to be implemented in both places and also in the new code path for the
introduced feature.
By sharing this code, it is much easier to guarantee that all code paths
behave the same. This approach is already implemented by other DSA drivers
like qca8k, mt7530 or ksz.
Sven Eckelmann [Thu, 9 Oct 2025 11:56:19 +0000 (13:56 +0200)]
realtek: Switch booleans in rtl838x_port to single bits
In upstream kernel, it is not well received to use a lot of simple booleans
in structs. It is preferred to use 1-bit bitfields [1] and consolidate the
booleans together.
Robert Marko [Sun, 12 Oct 2025 09:59:34 +0000 (11:59 +0200)]
ipq-wifi: add Yuncore AX850
It seems that adding Yuncore AX850 was missed during the board support,
and this breaks buildbots for ipq50xx with:
ERROR: unable to select packages:
ipq-wifi-yuncore_ax850 (no such package):
required by: world[ipq-wifi-yuncore_ax850]
make[4]: *** [/builder/shared-workdir/build/include/image.mk:396: target-dir-90b51871] Error 1
make[4]: *** Waiting for unfinished jobs....
So, add the required meta package.
Fixes: 5d2994a73e20 ("qualcommax: ipq50xx: Add support for Yuncore AX850") Signed-off-by: Robert Marko <robimarko@gmail.com>
Daniel Golle [Wed, 8 Oct 2025 17:57:16 +0000 (18:57 +0100)]
uboot-mediatek: update to U-Boot v2025.10
The most relevant change is the removal of the empty board_init()
functions by u-boot/u-boot@70a4d1fa1dd, which makes many patches not
apply anymore and also requires most board defconfigs to be updated
by adding "# CONFIG_BOARD_INIT is not set" to them.
Also some config symbols have been renamed and downstream boards
had to be adapted accordingly:
u-boot/u-boot@0fd9a3480a0 ("env: Rename OVERWRITE_ETHADDR_ONCE to
ENV_OVERWRITE_ETHADDR_ONCE")
u-boot/u-boot@5fb88fa725d ("env: Rename SYS_REDUNDAND_ENVIRONMENT to
ENV_REDUNDANT")
u-boot/u-boot@123682c7651 ("env: Rename SYS_RELOC_GD_ENV_ADDR to
ENV_RELOC_GD_ENV_ADDR")
u-boot/u-boot@0f44d5549ed ("env: Rename SYS_MMC_ENV_DEV to
ENV_MMC_DEVICE_INDEX")
u-boot/u-boot@31617b880ab ("env: Rename SYS_MMC_ENV_PART to
ENV_MMC_EMMC_HW_PARTITION")
u-boot/u-boot@ffc4914703a ("env: Rename ENV_MMC_PARTITION to
ENV_MMC_SW_PARTITION")
u-boot/u-boot@fb5235239aa ("env: Rename DEFAULT_ENV_FILE to
ENV_DEFAULT_ENV_TEXT_FILE")
(also renamed USE_DEFAULT_ENV_FILE to USE_ENV_DEFAULT_ENV_TEXT_FILE)
Jonas Jelonek [Wed, 8 Oct 2025 08:19:25 +0000 (08:19 +0000)]
realtek: pcs: add more SerDes access helpers
Add more SerDes access helpers for the upcoming code import from PHY
driver. There, similar helpers are used to read and write full SerDes
registers or only parts of them (aka bitfields).
The helpers are expected to replace the following used in PHY SerDes
code:
- rtl9300_sds_field_r
- rtl9300_sds_field_w
- rtsds_931x_read
- rtsds_931x_read_field
- rtsds_931x_write
- rtsds_931x_write_field
Mark the helpers as unused for now to make the compiler happy. This will
be removed as soon as they are used.
There are two spi drivers for en7523/an7581/an7583:
* en7581-snand (spi-airoha-snfi.c)
* en7523-spi (spi-en7523.c)
The first one supports DMA, but until recently it has several nasty
issues. The second do things properly but does not support DMA.
Recently the first driver was greatly improved, so there is no sence
keep both drivers anymore.
This patch removes en7523-spi driver and use DMA capable driver instead.
Unfortunately there is a nasty en7523 specific issue.
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of it's BOOT pins. This will lead
to booting in RESERVED boot mode. It was found that some flashes operates
incorrectly in RESERVED mode if DMA used.
This patch also adds a hack that turns off DMA and prints big fat warning
if booting in reserved mode was detected. This slow down flash operations
but does not kill your data.
boot: airoha: snfi: remove dirty hack required for both u-boot & linux
This patch removes dirty hack used to:
* operate with flash
* pass flash page settings to linux driver via SNFI registers
It has been proven that spinand flash page size is actually unnecessary.
We can get all required data from dirmap requests. Thus this patch
series drops the hack and do things properly.
After this fix (and corresponding linux fix) the hack is not needed
anymore.
This patch series removes dirty hack that reads flash page settings from
SNFI registers during driver startup.
Before these patches the airoha spi snfi driver needs to know spinand
flash page size. The driver can't get it from spinand subsystem, so the
following approach was implemented:
* bootloader know the flash page size (and some other parameters)
* to operate properly the bootloader writes flash page size (and some
other parameters) to SNFI registers
* bootloader starts linux
* after linux start SNFI registers keeps the values stored by bootloader
* linux snfi driver reads flash parameters from SNFI registers.
This works, but we can do better. It has been proven that flash page size
is actually unnecessary. We can get all required data from dirmap requests.
This patch series drops the hack and do things properly.
This patch series greatly improve airoha snfi driver and fix a
number of serious bugs.
Fixed bugs:
* Fix reading/writing of flashes with more than one plane per lun
* Fill the buffer with 0xff before writing
* Fix reading of flashes supporting continuous reading mode
* Fix error paths
Improvements:
* Add support of dual/quad wires spi modes in exec_op(). This also
fix flash reading/writing if dirmap can't be created.
* Support of dualio/quadio flash reading commands
Continuous reading mode is broken for some spi controllers. There are two
possible bug scenarios:
1) "continuous mode" flash and spi controller without dirmap support,
but with restriction on transfer length in adjust_op_size()
2) "continuous mode" flash and spi controller with dirmap support for a
single flash page
In the first case, any read that exceeds the limit specified in adjust_op_size()
will result in an EIO error. The limit may even be less than a size of a single
flash page. In this case, any read will result in an error.
In the second case, any read larger than flash page size will result in an EIO
error or spinand driver spoofing (because the spi controller driver returns
more bytes than were actually read).
This patch series tries to fix continuous reading (spinand driver side).
Unfortunately these fixes can't resolve "spinand driver spoofing" case.
Spi controller drivers might need fixes as well.
Petr Štetiar [Mon, 6 Oct 2025 19:41:03 +0000 (19:41 +0000)]
tools: xxhash: fix PKG_MIRROR_HASH
Current PKG_MIRROR_HASH is wrong, but it went unnoticed, because the
tarball is being fetched from @OPENWRT project mirrors. After 042996b46bd revert the correct hash can be reproduced with:
make tools/xxhash/{download,check} FIXUP=1 DL_DIR=/tmp PKG_MIRROR_HASH=''
qualcommax: ipq50xx: Add support for Yuncore AX850
Specifications:
SOC: Qualcomm IPQ5018 (64-bit dual-core ARM Cortex-A53 @ 1.0Ghz)
Flash: SPI NOR 8MB (Winbond W25Q64DW) + NAND 128MB (Winbond W25N01GWZEIG)
Memory: 512MB DDR3L
Standard: 802.11ax/ac/b/g/n
2.4G Frequency: 2.4GHz - 2.484GHz
2.4G Wi-Fi standard: 802.11b/g/n/ax
5G Frequency: 5.150GHz~5.850GHz
5G Wi-Fi Standard: 802.11 a/n/ac/ax
Buttons: 1 * Reset button, press 10 seconds to revert to default setting
2.4G Antenna: 2*2.4GHz/5.8GHz dual band antenna: 4dBi
5G Antenna: 2*5.8G antenna: 4dBi
Data Rate: 2.4GHz: 574Mbps, 5GHz:4800Mbps
Power: PoE 802.3at，DC2.0 12V/2A
Max Power Consumption: < 22W
LED Light: WAN, LAN, tricolor LED(sys-red, 2.4G-green, 5.8G-blue)
BACKUP YOUR STOCK FIRMWARE:
- Put openwrt-*-initramfs-uImage.itb to your
TFTP server and rename it to initramfs.bin
- Enable serial console and enter to u-boot cli
and exec these commands:
```
tftpboot <your_tftp_server_ip>:initramfs.bin
bootm
```
- Once boot completed and you get the openwrt shell
execute below commands:
```
device=ax850
mkdir -p /tmp/fw_backup; cd /tmp/fw_backup
rootfs=$(cat /proc/mtd | grep \"rootfs\" | cut -d: -f1)
rootfs_1=$(cat /proc/mtd | grep \"rootfs_1\" | cut -d: -f1)
dd if=/dev/${rootfs} of=rootfs_${rootfs} bs=1M
dd if=/dev/${rootfs_1} of=rootfs_1_${rootfs_1} bs=1M
cp /sys/firmware/fdt fdt.dtb
md5sum * > md5sum
tar -cvzf /tmp/${device}.tar.gz .
sum=$(md5sum /tmp/${device}.tar.gz | cut -d' ' -f1)
mv /tmp/${device}.tar.gz /tmp/${device}_${sum}.tar.gz
echo "stock fw backup saved to: /tmp/${device}_${sum}.tar.gz"
```
- Upload/save your backup to a safe place.
STOCK FIRMWARE RECOVERY:
- Boot initramfs image
- Upload your backed-up stock fw tarball to the device
using scp or download it from the device using wget.
- Enter device ssh cli or tty and exec:
```
cd /tmp && wget <your_web_server_ip>/${stock_fw_backup}.tar.gz`
tar -xpzf ${stock_fw_backup}.tar.gz
rootfs=$(cat /proc/mtd | grep \"rootfs\" | cut -d: -f1)
rootfs_1=$(cat /proc/mtd | grep \"rootfs_1\" | cut -d: -f1)
ubiformat /dev/${rootfs} -y -f /tmp/rootfs_${rootfs}
ubiformat /dev/${rootfs_1} -y -f /tmp/rootfs_1_${rootfs_1}
reboot
```
INSTALLATION:
1. initramfs method
- Put openwrt-*-initramfs-uImage.itb to your
TFTP server and rename it to initramfs.bin
- Enable serial console and enter to u-boot cli
and exec these commands:
```
tftpboot <your_tftp_server_ip>:initramfs.bin
bootm
```
- Once boot completed and you get the openwrt shell
execute below commands:
```
cd /tmp && wget <your_web_server_ip>/factory.ubi`
export rootfs=$(cat /proc/mtd | grep rootfs | cut -d: -f1)
export rootfs_1=$(cat /proc/mtd | grep rootfs_1 | cut -d: -f1)
ubiformat /dev/${rootfs} -y -f factory.ubi
ubiformat /dev/${rootfs_1} -y -f factory.ubi
reboot
```
2. u-boot factory.ubi image method
- Put factory.ubi to your TFTP server and
enter u-boot cli and exec these commands:
```
tftpboot <your_tftp_server_ip>:factory.ubi
#After downloading is finished:
flash rootfs
flash rootfs_1
reset
```
Paul Spooren [Wed, 8 Oct 2025 09:42:51 +0000 (11:42 +0200)]
package: do not sign individual APK packages
APK, unlike OPKG, can sign individual packages and not just indexes.
Since OpenWrt uses a distributed build infrastructure and only the build
master owns the private keys, signing of individual buildworkers doesn't
work. Right now, each buildworker creates a temporary build key to sign
packages, then transmits the package index to the buildmaster for a
signature.
As a result, all individual packages contain a nonsensical signature,
making them harder to reproduce. This commit removes the individual
package signing.
Since APK requires signatures per default, explicitly allow installation
of unsigned packages during the build process.
The config option here is for historical reasons misleading,
SIGNED_PACKAGES refers to the package index, not the individual
packages.
projects / thirdparty / openwrt.git / log
