Increase the spi-max-frequency from 20MHz to 52MHz for the SPI-NAND flash
on the Mercusys MR90X v1. The underlying GigaDevice GD5F1GQ5UEYIGY
SPI-NAND flash chip natively supports clock speeds up to 133MHz and the
MediaTek MT7986B SoC handles 52MHz safely.
Testing with 'dd' reading 16MB from /dev/mtd3 shows a significant
performance improvement (~49% reduction in read time):
Before (20MHz):
256+0 records in
256+0 records out
real 0m 2.71s
After (52MHz):
256+0 records in
256+0 records out
real 0m 1.37s
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25246
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Increase the spi-max-frequency from 20MHz to 52MHz for the SPI-NAND flash
on the Mercusys MR90X v1. The underlying GigaDevice GD5F1GQ5UEYIGY
SPI-NAND flash chip natively supports clock speeds up to 133MHz and the
MediaTek MT7986B SoC handles 52MHz safely.
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25246
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Changelog: https://github.com/the-tcpdump-group/libpcap/blob/libpcap-1.10/CHANGES
CVE fixes:
- CVE-2026-0799: Access M[] safely in the BPF interpreter.
- CVE-2026-31912: Mind the program bounds in pcap_offline_filter().
- CVE-2026-31911: Fail opcodes safely in the BPF interpreter.
- CVE-2026-6244: Avoid division by zero via pcap_offline_filter().
- CVE-2026-6554: Limit "ja L" looping in pcap_offline_filter().
- CVE-2026-18313: Fix a memory leak in rpcapd.
- CVE-2026-18238: Fix RPCAP_MSG_PACKET validation.
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25384
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
trx_fixup() computed the CRC32 range from the on-flash TRX header
without validating it:
scan = ptr + offsetof(struct trx_header, flag_version);
trx->crc32 = crc32buf(scan, trx->len - (scan - ptr));
trx->len is read from the mmap()ed partition and is only sanity checked
in trx_check(), which is a separate entry point. A trx->len larger than
the partition therefore makes crc32buf() walk that many bytes past the
end of the mapping and crash mtd with SIGSEGV.
The mirror case of a trx->len below the 12 byte offset does not overread
in practice: crc32buf() takes a size_t but passes it to crc32(), which
takes an int len and loops on "while (--len >= 0)". The wrapped value
truncates to a negative int, so the loop body never runs and a zero
length CRC32 is written instead. Values at or above 0x8000000c truncate
the same way. Only the range from sizeof(struct trx_header) to roughly
0x8000000b stays positive through the truncation and reads out of
bounds, which is exactly the range a plausible bad length falls into.
Bound trx->len on both sides before computing the range, using the same
lower limit trx_check() already applies. Both comparisons are unsigned,
so the wrapping cases are rejected as well.
trx_fixup() runs as root on the contents of the flash, so this is a
robustness fix rather than a privilege boundary: it is reachable through
"mtd jffs2write" and the jffs2_replaced path of "mtd write", not through
"mtd fixtrx", which uses mtd_fixtrx() and derives its length from
erasesize instead. The practical benefit is not crashing on a truncated
or corrupted header during sysupgrade.
Link: https://github.com/openwrt/openwrt/security/advisories/GHSA-wch3-f5gc-mw2h
Reported-by: @tonoyx91
Reported-by: @0xROI
Fixes: bbd9eb4669 ("clean up mtd, fix up trx header when integrating jffs2 data on broadcom devices")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25284
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When the TRX magic check fails, trx_fixup() jumps straight to the err
label, which only returns -1. At that point the mtd device has already
been opened and the whole partition has been mmap()ed, so both the file
descriptor and the mapping are leaked.
Add an err2 label that unwinds the mapping before falling through to the
existing close(bfd), so the error path unwinds in reverse order of
acquisition like the success path does.
Fixes: bbd9eb4669 ("clean up mtd, fix up trx header when integrating jffs2 data on broadcom devices")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25284
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add missing syscall names needed on 32-bit platforms to the pre-main
pre-main syscall allowlists.
Fixes: #25392
Fixes: ee526dbf01 ("procd: update to git HEAD of 2026-09-13")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
EDMA maps RX fill buffers with DMA_TO_DEVICE but unmaps them with DMA_FROM_DEVICE. Use DMA_FROM_DEVICE consistently, release mappings left on RX rings during teardown, and flush ring-disable writes before descriptor cleanup.
Signed-off-by: krava <igor.kravchenko05@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24218
Signed-off-by: Robert Marko <robimarko@gmail.com>
Kernel modules from the packages feed differ between builds on 6.18,
e.g. kmod-v4l2loopback, kmod-jool-netfilter, kmod-pf-ring and
kmod-usb-serial-dmx_usb_module:
-/builder/shared-workdir/build/build_dir/.../linux-6.18.52/include/linux/ucopysize.h
+/tmp/rebuilderd-openwrt.Xebb8P/src/build_dir/.../linux-6.18.52/include/linux/ucopysize.h
These packages call make -C $(LINUX_DIR) M=... without
KERNEL_MAKE_FLAGS, so they get none of the OpenWrt prefix maps. With
6.12 that did not matter, since srctree stayed "." and the kernel
headers were included by a relative path. Since 6.13 srctree holds the
absolute path of the kernel tree for external modules, while kbuild
only maps srcroot, the module directory.
Add a pending patch that maps the kernel tree for external modules too.
It is added before the map of srcroot and before KCFLAGS, and GCC uses
the last matching map, so modules built through KERNEL_MAKE_FLAGS keep
their current output.
Link: https://github.com/openwrt/openwrt/pull/25356
Signed-off-by: Paul Spooren <mail@aparcar.org>
Add upstream patch marking the 'gpll0_main' clock as critical on
IPQ5018 (gcc-ipq5018 driver), backported from upstream commit
33f9cb56cc28 ("clk: qcom: gcc-ipq5018: mark 'gpll0_main' clock as
critical").
During boot the APCS core clock feeding the CPUs can use GPLL0 as
its parent. On some boards (e.g. TP-Link Archer AX55 v1 using the
in-tree DTS since v6.18), the ipq-cmn-pll driver's pm_runtime_put()
call in its probe function asynchronously disables
'gcc_cmn_blk_ahb_clk', which in turn disables 'gpll0_main' as well,
hanging the system until the hardware watchdog restarts the board.
Marking gpll0_main as CLK_IS_CRITICAL fixes the underlying issue
directly in the GCC driver, making the previous workaround in
0191-clk-qcom-ipq-cmn-pll-keep-the-CMN-block-bus-clocks-enabled.patch
unnecessary. Drop that patch, as it addressed the same symptom by
keeping the CMN PLL block's bus clocks permanently enabled via a
devres-managed runtime PM reference instead of fixing the actual
critical clock.
Refresh the context in
0721-clk-gcc-ipq5018-remove-the-unsupported-clk-combinati.patch and
0723-clk-qcom-gcc-ipq5018-fix-uniphy-soft-reset-issue.patch, whose
hunks shifted by 9 lines due to the newly inserted patch.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/25386
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add thermal zone for the Wi-Fi chip using the same trip levels and cooling maps as the CPU. The
kernel thermal governor will act on whichever temperature is the highest. There is only a single
heatsink and fan to cover both the SoC and Wi-Fi chip, so tracking both CPU and Wi-Fi temperatures
ensures that neither chip will overheat from low fan speed.
The trip levels are spaced 1.25C apart with double that (2.5C) for the hysteresis, with 5C
hysteresis for the lowest trip level (65C) because it is preferable for the fan to run for longer at
low speed than to stop and start repeatedly.
In the absence of continuous proportional feedback control, tightly grouping the trip levels and
cooling maps minimises the frequency and amplitude of temperature and fan speed oscillations.
The cooling states are set to increments of 5 (out of 255) from 12% to 61% and then increments of 10
from 61% to 100% with kick start speed at 15%. In comparison, the default in mt7981b.dtsi starts at
50% fan speed and leads to constant on/off cycles within a short period of time (every ~2 minutes).
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22936
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Add a common dtsi with macros for thermal trip levels and cooling maps that can be included in other
device trees.
The trip levels are spaced 1.25C apart with double that (2.5C) for the hysteresis, with 5C
hysteresis for the lowest trip level (65C) because it is preferable for the fan to run for longer at
low speed than to stop and start repeatedly.
In the absence of continuous proportional feedback control, tightly grouping the trip levels and
cooling maps minimises the frequency and amplitude of temperature and fan speed oscillations.
There are 36 trip levels and the cooling maps start from cooling state 1 (0-index) so cooling-levels
must have at least 37 elements. If greater increments between trip levels/cooling-levels are desired
or needed the cooling-levels can be padded with repeated values.
The THERMAL_TRIPS_COMMON and THERMAL_COOLING_MAPS_COMMON macros take one argument as the prefix to
the trip levels node labels. The prefix must be the same within a thermal zone.
Signed-off-by: Ryan Leung <untilscour@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22936
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
OpenWrt's custom uImage magic patch makes legacy image verification use
params.magic instead of IH_MAGIC.
mkimage initializes this field, while dumpimage leaves it zeroed. This
causes dumpimage to reject valid legacy uImages using the standard
IH_MAGIC with FDT_ERR_BADMAGIC.
Initialize dumpimage's magic to IH_MAGIC so the normal verification path
works by default. Also add -M handling matching mkimage, allowing
dumpimage to verify and extract uImages built with a custom magic.
Tested with the patched U-Boot 2026.07 host tools. Standard-magic images
list and extract correctly, custom-magic images are accepted with the
matching -M value, and are rejected without it or with an incorrect
magic. Extracted payloads were verified byte-for-byte.
Fixes: #25287
Signed-off-by: Massimo Mazzariol <mazzariol.massimo@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25288
Signed-off-by: Robert Marko <robimarko@gmail.com>
The post_config hooks finalize a powered-up SerDes and may calibrate
its receiver. Configure autonegotiation and the BMCR speed first so
finalization runs with the requested PCS state.
This is required for 100BASE-X on RTL930x. Calibrating with the default
1000 Mbps BMCR setting produced symbol errors until BMCR was switched
to 100 Mbps.
Preserve the changed result from set_autoneg across the post_config
callback so pcs_config keeps its existing return semantics.
Tested runtime mode transitions and cold boot on RTL838x, RTL930x and
RTL931x. Links came up and passed traffic in all tested modes with no
regressions observed.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Phylink can only request interface modes advertised by the DSA port.
Expose 100BASE-X when the SoC MAC capabilities include MAC_100 so that
ports backed by a capable PCS can select the newly supported mode.
Keep this independent of MAC_1000FD because the 100 Mbps and 1 Gbps MAC
capabilities are reported separately.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The generic, RTL930x, and RTL931x setup paths now handle 100BASE-X.
Add the RTL93xx hardware mode value and mapping, select the 1G analog
CMU page, and advertise the mode from RTL93xx SerDes instances.
This makes the prepared support available to PCS consumers.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL931x handles 100BASE-X through its 1G fiber digital path, but the
FIB1G link detector must remain disabled at 100 Mbps.
Add 100BASE-X to the fiber setup and symbol-error handling paths. Share
the 1000BASE-X setup while selecting the appropriate FIB1G link-enable
value for each mode. Keep the mode unavailable until the shared
RTL93xx support is enabled.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL930x uses the IP-driven mode setup for Base-X links and the 1G
analog configuration for SGMII and 1000BASE-X.
Route 100BASE-X through the same IP-driven and 1G analog setup paths.
Keep the mode unavailable until all RTL93xx support is in place.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
100BASE-X uses a direct SerDes attachment and the same 1G-class PLL
configuration as 1000BASE-X on the supported hardware.
Teach the common attachment and PLL selectors about the mode. This is
preparation only; no additional SerDes advertises support yet.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
100BASE-X does not use in-band autonegotiation and requires BMCR to
select 100 Mbps. Extend the generic autonegotiation helper to always
disable AN for this mode and then program BMCR_SPEED100.
This ordering is required on RTL93xx, which ignores speed-selection
updates while BMCR_ANENABLE is set.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL93xx ignores BMCR speed-selection updates while BMCR_ANENABLE is
set. The RTL931x mode setup therefore cannot reliably select 1000 Mbps
for forced 1000BASE-X before generic autonegotiation handling runs.
Move forced 1000BASE-X speed selection into the generic helper and
perform it after disabling autonegotiation. This also removes the
ineffective RTL931x-specific write.
Link: https://github.com/openwrt/openwrt/pull/25378
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Some of these GPIOs are shared between interfaces. Use a regulator to be
able to share them. Enable Kconfig options so that they work.
Backport one patch upstream so the patch applies. Rename another to
clarify it's in 7.2.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25296
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Use the realtek-pse-mcu kernel driver instead of realtek-poe. The MCU
is a Nuvoton M05xx using the gen1 protocol over UART at 19200 baud.
realtek-poe turns off the MCU's port mapping at startup, which reversed
the PoE port numbering and the front-panel PoE LEDs. The kernel driver
leaves the mapping alone, so both now match the front panel. The MCU
keeps this state across a warm reboot, so a unit sysupgraded from a
realtek-poe image stays reversed until its first power cycle.
Tested on a GS110TPP v1: the driver probes the MCU and its BCM59121,
and a PoE device on lan1 is powered.
Signed-off-by: Kel Modderman <kelvmod@gmail.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/25298
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
CompileBPF calls clang with -g but without any prefix map. Stripping debug info
keeps .BTF and .BTF.ext, since libbpf needs them, and their line info carries
the absolute path of each source file. This makes BPF objects like qosify-bpf.o
depend on the build directory and breaks reproducibility:
-/builder/shared-workdir/build/build_dir/.../qosify-bpf.c
+/tmp/rebuilderd-openwrt.juCsuQ/src/build_dir/.../qosify-bpf.c
IREMAP_CFLAGS is not enough here: without CONFIG_REPRODUCIBLE_DEBUG_INFO it
only sets -fmacro-prefix-map, which leaves the line info alone, and it is empty
for external toolchains, which have no say over the host clang. Unlike regular
debug info, BTF ships with the package, so always pass -ffile-prefix-map for
the build and staging directories.
Add an fremap helper next to iremap for that, and let IREMAP_STAGING_DIR and
CompileBPF share the map of the staging directory, so they cannot drift apart.
Link: https://github.com/openwrt/openwrt/pull/25359
Signed-off-by: Paul Spooren <mail@aparcar.org>
The x86 and armsr targets declare the vdi, vmdk and vhdx features, but
VDI_IMAGES, VMDK_IMAGES and VHDX_IMAGES depend on a hardcoded target
list instead, so the features select nothing and a target opting in has
to edit config/Config-images.in.
Give them USES_VDI, USES_VMDK and USES_VHDX in the same shape as the
other image formats and depend on those. The set of targets offering
each format is unchanged.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The atm feature has no entry in target_config_features(), so it selects
no symbol, and nothing else reads the feature list beyond the broken and
source-only filters. It has never gated anything. The kmod-ltq-atm-*
packages are unrelated name matches, pulled in through DEFAULT_PACKAGES.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
"\s" is not an escape sequence in a Perl double-quoted string, so the
pwm feature emits its select statement without the leading tab that
every other feature gets. Kconfig accepts the unindented line, but the
generated target/Config.in is inconsistent.
Fixes: f6fbc39706 ("build: define PWM_SUPPORT arch feature flag")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The ubus notification for link measurements was added by replacing the
call to hostapd_handle_link_mesr_report() instead of adding to it, so
upstream's handler lost its only caller and is compiled out as dead
code, which the build shows as:
src/ap/rrm.c:354:13: warning: 'hostapd_handle_link_mesr_report'
defined but not used [-Wunused-function]
As a result nothing clears hapd->link_mesr_req_active or cancels
hostapd_link_mesr_rep_timeout_handler() when a report arrives, so a
REQ_LINK_MEASUREMENT issued over the control interface always ends in a
timeout even though the report was received, and the LINK-MSR-RESP-RX
event carrying the report is never emitted.
Call both handlers, which is how the ubus hook for beacon reports a few
lines above is wired up too.
Fixes: f6445cfa1a ("hostapd: add ubus link-measurements notifications")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25242
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
apup_process_beacon() adds the peer with ap_sta_add() and only asks for
an AID with hostapd_get_aid() further down. When that fails the function
returns without undoing anything, leaving the station in hapd->sta_list
with WLAN_STA_AUTH set but with no AID, no WLAN_STA_ASSOC and no WDS
interface. The driver entry added by the preceding hostapd_sta_add() and
the hapd->num_sta reference are leaked as well.
The leftover entry is then found by the ap_get_sta() check at the top of
the function, so every later beacon from that BSSID returns early and
the peer can never be set up again until hostapd is restarted.
Release the half-initialised station with ap_free_sta(), which removes
the driver entry, cancels the inactivity timer registered by
ap_sta_add(), unlinks it from the list and drops the counters.
Fixes: e80520197c ("hostapd: Add support for APuP")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25242
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
apup_process_beacon() dereferenced the return value of ap_sta_add()
without checking it. ap_sta_add() returns NULL when the station table is
full, when the allocation fails or when accounting_sta_get_id() fails,
so the following read of sta_ret->aid dereferences NULL.
The station table filling up is remotely triggerable. Beacons reach
handle_beacon() on every softmac driver, because hostapd subscribes to
them per wiphy with NL80211_CMD_REGISTER_BEACONS when it starts the AP.
An adjacent station can therefore beacon the target's SSID from
successive spoofed BSSIDs, each of which is added as an APuP peer, until
max_num_sta is reached and hostapd crashes.
CONFIG_APUP=y is set unconditionally in DRIVER_MAKEOPTS, so the code is
compiled into every wpad variant, but the call is gated on
hapd->conf->apup at runtime and wifi-scripts defaults apup to 0. Only
configurations that opt into APuP are affected.
Reported-by: JuliusBairaktaris
Fixes: e80520197c ("hostapd: Add support for APuP")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25242
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This appears to reduce the CPU temp by at least a few degrees C on
Linksys EA4500, which is notorious for its thermal challenges.
Tested only on EA4500 by running without issues for a few weeks under a
light workload.
Signed-off-by: Will Mortensen <willmo@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25276
Signed-off-by: Robert Marko <robimarko@gmail.com>
Armada 38x uses Cortex-A9 r4p1, but the current kernel config selects
erratum 720789, which was fixed in r2p0, and omits some errata that
still affect r4p1. Fix the config.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25297
Signed-off-by: Robert Marko <robimarko@gmail.com>
The WR3000S has a GPIO LED behind its front-panel "Internet" lamp
(white:wan-online, &pio 11), but no board.d entry, so no trigger is ever
set and the lamp stays dark. Give it the same netdev trigger the WR3000H
and WR3000P already use for their white:wan-online LED: follow the link
state of the wan port. As on those boards, "link" means the wan port has
carrier, not that connectivity works.
The panel's WAN and LAN1-4 lamps are not GPIO LEDs and are not registered
as Linux LEDs at all; they light on link in hardware, so board.d cannot
address them and they are untouched here. The -ubootmod variant includes
the same mt7981b-cudy-wr3000s-v1.dtsi, and so the identical LED, and is
listed alongside.
Tested on a WR3000S v1 (OEM layout), on an image built from main at
6727587d24 plus this commit: after a config-wipe sysupgrade the board.d
entry is applied automatically (board.json -> system.led_internet), the
lamp lights while the WAN port has link, and it goes dark when it loses
link. Only the OEM-layout variant was flashed.
Signed-off-by: Ivan Rainbolt <ivan@github.ivanthegeek.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/25335
Signed-off-by: Robert Marko <robimarko@gmail.com>
The driver doesn't really care about the address in dts, but might as
well fix it anyway.
0 is just wrong.
1f is the address for the builtin FE switch, not the external gigabit
switch.
10 is the driver default.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25370
Signed-off-by: Robert Marko <robimarko@gmail.com>
The APEX boot loader embeds the time of the build in its version
banner, which makes the Iomega NAS100D factory image differ between
builds:
-compiled for OpenWrt NAS100D/BE on 2026.Sep.23-04:17:21
+compiled for OpenWrt NAS100D/BE on 2026.Sep.23-11:06:03
APEX sets BUILDDATE with $(shell date) in its top level Makefile. Pass
BUILDDATE on the command line, formatted from SOURCE_DATE_EPOCH in UTC
and the C locale, which overrides it for all sub-makes.
Link: https://github.com/openwrt/openwrt/pull/25354
Signed-off-by: Paul Spooren <mail@aparcar.org>
Since b69bb476dee9 ("cgroup: fix race between fork and cgroup.kill") the
fork path snapshots kill_seq in cgroup_css_set_fork() before the
CLONE_INTO_CGROUP target has been resolved, so it always records the
forking task's own cgroup while cgroup_post_fork() reads the target's
and compares the two. Once cgroup.kill has been written to a cgroup,
every child later cloned out of it into another cgroup is SIGKILLed
before it runs a single instruction, for as long as that cgroup exists.
This breaks re-creating an OCI container under procd, whose service
supervisor kills the instance cgroup on exit and leaves it in place: the
container init ujail clones with CLONE_INTO_CGROUP is killed at birth and
the create fails with no diagnostic. The fix is in mainline from v7.3-rc2
and carries Cc: stable, so it is expected to reach 6.18.y with a future
stable release, at which point this patch can be dropped.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The Charter Spectrum SBE1V1K fails to boot with the default kernel
load address. The device gets stuck early in the boot process due to
the stock bootloader encountering memory overlap or alignment issues
with the default `0x41000000` address.
Changing `KERNEL_LOADADDR` to `0x42200000` resolves the boot failure
and ensures stable operation.
Why `0x42200000` instead of `0x42000000`?
While testing showed that `0x42000000` also boots successfully,
`0x42200000` was explicitly chosen for two primary safety reasons:
1. Avoid U-Boot `loadaddr` Overlap: On many QCA/IPQ platforms,
`0x42000000` is commonly used as the default `loadaddr` to fetch
the FIT image into memory. Setting the extraction destination
(`KERNEL_LOADADDR`) to the exact same base address risks in-place
decompression overlaps.
2. Reserved Memory Buffer: The memory range below `0x42000000`
is heavily utilized by TZ, SMEM, and vendor-specific reserved
memory in newer Askey firmwares. Adding a 2MB aligned offset
(`0x200000`) provides a safer buffer against shifting vendor
memory boundaries in future OEM bootloader updates, while still
strictly satisfying the ARM64 2MB alignment requirement.
This fix and the `0x42200000` address have been successfully tested
on actual SBE1V1K hardware by community member motolav.
Link: https://forum.openwrt.org/t/spectrum-sbe1v1k-ipq9574-openwrt-support/245244/262
Tested-by: motolav <https://forum.openwrt.org/u/motolav>
Signed-off-by: Jackie Han <jackie.han@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25344
Signed-off-by: Robert Marko <robimarko@gmail.com>
The driver carried the constants for all three sensors but registered
one zone and read only the bandgap one. Register a zone per sensor and
add two zones to the device tree.
The bandgap sensor stays zone 0 with its trips and cooling map.
#thermal-sensor-cells goes from 0 to 1.
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25147
Signed-off-by: Robert Marko <robimarko@gmail.com>
Two thermal zones reading the shared ADC at once interleave and convert
another sensor's diodes with the wrong constants. On AN7583 the zone
carrying the critical trip crossed 120 C on a chip at 55 C, shutting the
board down.
Serialise the sequence, read the mux selection back instead of caching
it, check it again after sampling and refuse to divide by a zero gain.
Signed-off-by: Vitaliy Sochnev <sochnev.v.74@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25147
Signed-off-by: Robert Marko <robimarko@gmail.com>
Andrew LaMarche
Mikhail Zhilkin
Ivan Pavlov
Hauke Mehrtens
Daniel Golle
krava
Robert Marko
Paul Spooren
Mieczyslaw Nalewaj
Ryan Leung
Massimo Mazzariol
Jonas Jelonek
Rosen Penev
Kel ModdermanandClaude Opus 5.5
Will Mortensen
Qingfang Deng
Ivan RainboltandClaude Opus 5
Shiji Yang
Jackie Han
Vitaliy Sochnev