From anykey196 at gmail.com Thu Oct 1 21:03:44 2026 From: anykey196 at gmail.com (Vladimir Savelev) Date: Fri, 2 Oct 2026 09:03:44 +0500 Subject: [PATCH] tools/fakeroot: update to 2.1.4 Message-ID: <20261002040344.1249101-1-anykey196@gmail.com> fakeroot 2.1.3 has been removed from Debian mirrors, causing build failures with HTTP 404 errors on all configured mirrors. Update to 2.1.4 which is available in Debian pool. This patch was prepared with the assistance of AI tools. Signed-off-by: OpenWrt AI Agent --- tools/fakeroot/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/fakeroot/Makefile b/tools/fakeroot/Makefile index f8b0233c1..41a5778ff 100644 --- a/tools/fakeroot/Makefile +++ b/tools/fakeroot/Makefile @@ -5,12 +5,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=fakeroot -PKG_VERSION:=2.1.3 +PKG_VERSION:=2.1.4 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)_$(PKG_VERSION).orig.tar.xz PKG_SOURCE_URL:=@DEBIAN/pool/main/f/fakeroot -PKG_HASH:=f28e33187b19ab0b6358ee40d5d8762f149cb19fa0423b6f40f605f5c80446bf +PKG_HASH:=0822bd5a9f0cf19d2ba0546b88b0432d4d3d9917db62c57b74044ccadba06e49 PKG_LICENSE:=GPL-3.0-or-later PKG_LICENSE_FILES:=COPYING PKG_FIXUP:=autoreconf -- 2.53.0 From anykey196 at gmail.com Fri Oct 2 00:15:30 2026 From: anykey196 at gmail.com (Vladimir Savelev) Date: Fri, 2 Oct 2026 12:15:30 +0500 Subject: [PATCH 2/2] uboot: build in-tree pylibfdt against Python 3 In-Reply-To: <20261002071523.1797318-1-anykey196@gmail.com> References: <20261002071523.1797318-1-anykey196@gmail.com> Message-ID: <20261002071530.1797378-1-anykey196@gmail.com> The SWIG interface shipped for pylibfdt uses Python 2 APIs outside the PY_VERSION_HEX guards: PyString_FromString() in the fdt_property typemap and PyInt_AsLong() in the int *depth typemap. The neighbouring typemaps are already guarded, so guard these two the same way. On a host with Python 3.12+ and GCC 14+ this fails to build pylibfdt with "implicit declaration of function 'PyInt_AsLong'" and -Wint-conversion errors, since Python 3 removed both names. This has been reported upstream: https://github.com/u-boot/u-boot/pull/1053 This patch was prepared with the assistance of AI tools. Signed-off-by: Vladimir Savelev --- ...s-dtc-pylibfdt-build-against-python3.patch | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 package/boot/uboot/patches/910-scripts-dtc-pylibfdt-build-against-python3.patch diff --git a/package/boot/uboot/patches/910-scripts-dtc-pylibfdt-build-against-python3.patch b/package/boot/uboot/patches/910-scripts-dtc-pylibfdt-build-against-python3.patch new file mode 100644 index 000000000..b3431798a --- /dev/null +++ b/package/boot/uboot/patches/910-scripts-dtc-pylibfdt-build-against-python3.patch @@ -0,0 +1,41 @@ +scripts: dtc: build pylibfdt against Python 3 + +The SWIG interface shipped for pylibfdt uses Python 2 APIs outside the +PY_VERSION_HEX guards: PyString_FromString() in the fdt_property typemap +and PyInt_AsLong() in the int *depth typemap. The neighbouring typemaps +are already guarded, so guard these two the same way. + +On a host with Python 3.12+ and GCC 14+ this fails to build pylibfdt +with "implicit declaration of function 'PyInt_AsLong'" and +-Wint-conversion errors, since Python 3 removed both names. + +This has been reported upstream: https://github.com/u-boot/u-boot/pull/1053 + +--- a/scripts/dtc/pylibfdt/libfdt.i_shipped ++++ b/scripts/dtc/pylibfdt/libfdt.i_shipped +@@ -1033,8 +1033,13 @@ + PyObject *buff; + + if ($1) { ++ %#if PY_VERSION_HEX >= 0x03000000 ++ resultobj = PyUnicode_FromString( ++ fdt_string(fdt1, fdt32_to_cpu($1->nameoff))); ++ %#else + resultobj = PyString_FromString( + fdt_string(fdt1, fdt32_to_cpu($1->nameoff))); ++ %#endif + buff = PyByteArray_FromStringAndSize( + (const char *)($1 + 1), fdt32_to_cpu($1->len)); + resultobj = SWIG_AppendOutput(resultobj, buff); +@@ -1070,7 +1075,11 @@ + + /* typemaps used for fdt_next_node() */ + %typemap(in, numinputs=1) int *depth (int depth) { ++ %#if PY_VERSION_HEX >= 0x03000000 ++ depth = (int) PyLong_AsLong($input); ++ %#else + depth = (int) PyInt_AsLong($input); ++ %#endif + $1 = &depth; + } + From anykey196 at gmail.com Fri Oct 2 00:15:23 2026 From: anykey196 at gmail.com (Vladimir Savelev) Date: Fri, 2 Oct 2026 12:15:23 +0500 Subject: [PATCH 1/2] tools/gmp: declare standard headers relied upon by gmp-impl.h Message-ID: <20261002071523.1797318-1-anykey196@gmail.com> gmp-impl.h guards its include with HAVE_STDINT_H, but that macro is not declared in acinclude.m4, so autoheader does not emit a template for it and it stays undefined in config.h. Since gmp-impl.h also uses intptr_t (guarded by HAVE_INTPTR_T, which *is* detected), builds fail with "unknown type name 'intptr_t'". The same applies to inttypes.h, unistd.h and sys/types.h, which configure.ac relies on the autoconf default tests for. Declare them with AH_TEMPLATE so autoheader emits the templates. This patch was prepared with the assistance of AI tools. Signed-off-by: Vladimir Savelev --- ...cinclude-m4-declare-standard-headers.patch | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 tools/gmp/patches/003-acinclude-m4-declare-standard-headers.patch diff --git a/tools/gmp/patches/003-acinclude-m4-declare-standard-headers.patch b/tools/gmp/patches/003-acinclude-m4-declare-standard-headers.patch new file mode 100644 index 000000000..09006cf70 --- /dev/null +++ b/tools/gmp/patches/003-acinclude-m4-declare-standard-headers.patch @@ -0,0 +1,30 @@ +Declare the standard headers relied upon by gmp-impl.h in acinclude.m4 + +gmp-impl.h guards its include with HAVE_STDINT_H, but that +macro is not declared in acinclude.m4, so autoheader does not emit a +template for it and it stays undefined in config.h. Since gmp-impl.h +also uses intptr_t (guarded by HAVE_INTPTR_T, which *is* detected), +builds fail with "unknown type name 'intptr_t'". + +The same applies to inttypes.h, unistd.h and sys/types.h, which +configure.ac relies on the autoconf default tests for. + +Declare them with AH_TEMPLATE so autoheader emits the templates. + +--- a/acinclude.m4 ++++ b/acinclude.m4 +@@ -1,5 +1,14 @@ + dnl GMP specific autoconf macros + ++dnl gmp-impl.h guards the standard header includes with these macros, and ++dnl relies on the autoconf default tests to detect them. Declare them here ++dnl so that autoheader emits the templates for config.h.in; otherwise they ++dnl end up undefined in config.h. ++AH_TEMPLATE([HAVE_STDINT_H], [Define to 1 if you have the header file.]) ++AH_TEMPLATE([HAVE_INTTYPES_H], [Define to 1 if you have the header file.]) ++AH_TEMPLATE([HAVE_UNISTD_H], [Define to 1 if you have the header file.]) ++AH_TEMPLATE([HAVE_SYS_TYPES_H], [Define to 1 if you have the header file.]) ++ + + dnl Copyright 2000-2006, 2009, 2011, 2013-2018 Free Software Foundation, Inc. + dnl From russell at personaltelco.net Fri Oct 2 12:00:05 2026 From: russell at personaltelco.net (Russell Senior) Date: Fri, 2 Oct 2026 12:00:05 -0700 Subject: REGRESSION: kernel: configure the kernel only when an input changed Message-ID: https://github.com/openwrt/openwrt/commit/e97e3f36bd5d48add83c5c7fba907600b12a653c This commit results in a regression on realtek switches (and perhaps elsewhere), where a stale initramfs kernel gets included in a subsequent squashfs image. See explanation here: https://pastebin.com/xhHsTQng. Reverting this commit was tested and fixes the problem. To reproduce, with a .config stub of: CONFIG_TARGET_realtek=y CONFIG_TARGET_realtek_rtl931x=y CONFIG_TARGET_realtek_rtl931x_DEVICE_zyxel_xs1930-12hp=y time make BUILD_LOG=1 IGNORE_ERRORS=m V=s target/linux/clean time make BUILD_LOG=1 IGNORE_ERRORS=m V=s $ ls -al bin/targets/realtek/rtl931x/*.bin time make -j1 BUILD_LOG=1 IGNORE_ERRORS=m V=s $ ls -al bin/targets/realtek/rtl931x/*.bin The squashfs-sysupgrade.bin file size will jump by a few megabytes in the second build and, more significantly, boots as an initramfs instead of a squashfs due to the kernel-embdedded cpio rootfs. -- Russell Senior russell at personaltelco.net From sjg at chromium.org Thu Oct 1 08:59:39 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 16:59:39 +0100 Subject: [PATCH 01/11] mtd: bind the block device without leaking on failure In-Reply-To: <891afb4991f1e6825b5715fc918e9a9eda210bd6.1790626459.git.daniel@makrotopia.org> References: <891afb4991f1e6825b5715fc918e9a9eda210bd6.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > mtd: bind the block device without leaking on failure > > add_mtd_device() allocates a slot to hold the mtd_info pointer that > mtd_bind() keeps, but drops the return value. mtd_bind() only logs and > returns on failure, so the slot leaks. A failed kmalloc() is ignored > too, leaving the master without a block device and no hint why its > partitions are unreachable. > > Move the bind into a helper that frees the slot when mtd_bind() fails > and warns with the errno in both cases. > > Fixes: e8a7453824b7 ("mtd: bind an mtd_blk device for non-NAND MTD masters") > Signed-off-by: Daniel Golle > > drivers/mtd/mtdcore.c | 37 ++++++++++++++++++++++++++----------- > 1 file changed, 26 insertions(+), 11 deletions(-) > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c > @@ -396,6 +396,31 @@ static struct device_type mtd_devtype = { > + /* > + * mtd_bind() keeps the passed pointer, so it needs storage that lives > + * as long as the block device; an MTD master is never removed. > + */ I don't think this holds for SPI flash. With DM_SPI_FLASH, 'sf probe' calls device_remove() on the existing flash device before probing it again (cmd/sf.c:135). spi_flash_std_remove() then calls spi_flash_mtd_unregister() -> del_mtd_device(), and the new probe calls add_mtd_device() again. Neither del_mtd_device() nor device_remove() unbinds the mtd_blk child, so each 'sf probe' allocates another slot and binds a second mtd_blk device under the same flash device, while the old one still points at the old slot. That leak is more frequent than the mtd_bind() failure fixed here. Please can you either skip the bind when mtd->dev already has a UCLASS_BLK child (device_find_first_child_by_uclass()), or unbind the block device and free the slot in del_mtd_device(), as patch 3 does for UBI? Either way, please update the comment. > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c > @@ -396,6 +396,31 @@ static struct device_type mtd_devtype = { > + kfree(mtdp); > +warn: > + pr_warn("mtd: %s: cannot bind a block device: %d\n", mtd->name, ret); mtd_bind() already does pr_err("Cannot create block device\n") on failure, so this prints two lines for one failure. Not a big deal, but you could drop the message from mtd_bind() (the SPI NAND caller in nand/spi/core.c already checks the return value) and keep this one, since it has the name and errno. Regards, Simon From sjg at chromium.org Thu Oct 1 08:59:45 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 16:59:45 +0100 Subject: [PATCH 02/11] cmd: ubi: report a failed UBI block device bind In-Reply-To: <1db5bc9548848bfee60b4548a5247935231e8ae3.1790626459.git.daniel@makrotopia.org> References: <1db5bc9548848bfee60b4548a5247935231e8ae3.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > cmd: ubi: report a failed UBI block device bind > > ubi_blk_bind_once() drops the ubi_bind() return value, so when the bind > fails the attach still reports success and the caller finds no ubi_blk > device with nothing to explain it. Not quite. The only failure path in ubi_bind() is blk_create_devicef(), which already calls pr_err("Cannot create block device") at the default LOGLEVEL, so the user does get a message today. What it lacks is the errno and any mention of UBI. Please can you reword this to match? > > Report the errno. The attach itself is not failed: UBI is available > either way and the block device is an optional view of it, so a UBIFS > user must not lose the partition because the block layer could not be > set up. > > Fixes: dec405d1653a ("cmd: ubi: create a ubi_blk device when attaching UBI") > Signed-off-by: Daniel Golle > > cmd/ubi.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > diff --git a/cmd/ubi.c b/cmd/ubi.c > @@ -690,7 +692,11 @@ static void ubi_blk_bind_once(void) > + ret = ubi_bind(parent); > + if (ret) > + printf("Cannot create UBI block device: %d\n", ret); A failure now prints two messages, and since the pr_err() in ubi_bind() has no trailing newline they run together: Cannot create block deviceCannot create UBI block device: -12 I suggest dropping the pr_err() from ubi_bind() so the caller does the reporting, as your patch 1 does in mtd_blk_bind_master(). Patch 3 already changes ubi_bind(), so it could go there or here. Alternatively, keep the message in ubi_bind(), add the errno and a newline, and leave this caller silent. What do you think? I agree with not failing the attach. Regards, Simon From sjg at chromium.org Thu Oct 1 08:59:57 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 16:59:57 +0100 Subject: [PATCH 05/11] boot: imagemap: do not resize a region the caller owns In-Reply-To: <7bbbd8ae1f506f1d50cae0cf224675811d324ff0.1790626459.git.daniel@makrotopia.org> References: <7bbbd8ae1f506f1d50cae0cf224675811d324ff0.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > boot: imagemap: do not resize a region the caller owns > > The extend path reserves memory at the recorded address and re-reads the > region into it. For a region recorded by imagemap_map_to() that address > belongs to the caller, which asked for the payload to be placed there: > imagemap reserves memory it was never given and overwrites whatever the > caller had put at the destination. > > Restrict the extend path to regions allocated from LMB by imagemap > itself. A larger request against a caller-owned region now falls through > to a fresh allocation, leaving the caller's memory untouched. > > Fixes: 9b41c7dbee96 ("boot: add imagemap on-demand loading from storage") > Signed-off-by: Daniel Golle > > boot/imagemap.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > diff --git a/boot/imagemap.c b/boot/imagemap.c > @@ -233,13 +233,18 @@ void *imagemap_map(struct udevice *dev, loff_t img_offset, ulong size) > + /* > + * Only a region this device allocated may be resized; > + * one recorded by imagemap_map_to() lives at an address > + * the caller chose and owns. > + */ > + if (!r->lmb_reserved) > + break; The logic looks right to me. imagemap_record() dedups on img_offset, so there is at most one match and the break is fine. Please can you add a test? For example, call imagemap_map_to(dev, 0, 64, dst) with a guard pattern in dst beyond 64 bytes, then imagemap_map(dev, 0, 256), and check that the guard bytes are unchanged, the returned pointer is not dst, and the new region is LMB-reserved. Without a test this is easy to break again. It may also be worth saying in the commit message that the fall-through replaces the caller's record in the table, via imagemap_record(). A later imagemap_map_to() to the same dst then misses the 'already mapped' shortcut and reads the data again. That is harmless, but not obvious from the description. > + lmb_free(addr, ALIGN(r->size, ARCH_DMA_MINALIGN), > + LMB_NONE); BTW, this is not from your patch, but it is the same class of bug the series is fixing. The old reservation is freed here, but r is only updated on success. Both the -ENOMEM and read-failure exits leave r->lmb_reserved true and r->ram pointing at memory that is no longer reserved. imagemap_cleanup() then frees it a second time, which could drop someone else's reservation, and a later imagemap_lookup() can return a pointer into unreserved memory. On the in-place read-failure path, r also still claims r->size valid bytes, although the partial read may have overwritten them. Perhaps those exits should drop the entry or re-reserve the old range? After patch 6, the in-place case could instead shrink the reservation back to old_size, since those bytes are still valid. It could go in this series or the follow-up, whichever you prefer. Regards, Simon From sjg at chromium.org Thu Oct 1 09:00:01 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 17:00:01 +0100 Subject: [PATCH 06/11] boot: imagemap: read only the bytes an extend adds In-Reply-To: <9a960bc5139c79b9f60f37f8ea6255e6e8a76c2a.1790626459.git.daniel@makrotopia.org> References: <9a960bc5139c79b9f60f37f8ea6255e6e8a76c2a.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > boot: imagemap: read only the bytes an extend adds > > Growing a region re-reads it from the start even when the reservation > was renewed at the same address and the leading bytes are still valid. > The translation table exists to avoid re-reading data that is already in > RAM, so the common case of probing a FIT header and then mapping the > whole structure pays for the header twice. > > Read only the range the larger request adds when the region has not > moved. A reservation that had to be placed elsewhere still needs the > whole range. > > Fixes: 9b41c7dbee96 ("boot: add imagemap on-demand loading from storage") This is an optimisation rather than a bug fix: the current code reads more than it needs to, but the result is correct. Please can you drop the Fixes: tag so this is not picked up as a stable fix? > Read only the range the larger request adds when the region has not > moved. A reservation that had to be placed elsewhere still needs the > whole range. Strictly, it doesn't need the whole range from storage. The old reservation has been freed but nothing has written over it, so the old bytes are still in RAM. A memmove() from the old address to the new one would keep them, and copes with the new block overlapping the old one, which is quite likely here. See also below. > Signed-off-by: Daniel Golle > > boot/imagemap.c | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > diff --git a/boot/imagemap.c b/boot/imagemap.c > @@ -261,8 +265,14 @@ void *imagemap_map(struct udevice *dev, loff_t img_offset, ulong size) > - ret = spl_load_region(&priv->info, img_offset, size, > - base); > + if (addr == old_addr) > + ret = spl_load_region(&priv->info, > + base_off + old_size, > + read_size - old_size, > + (char *)base + old_size); > + else > + ret = spl_load_region(&priv->info, img_offset, > + size, base); Just to check: how often is the addr == old_addr case taken in practice? LMB_MEM_ALLOC_ANY allocates top-down, so the FIT header region is normally the last allocation, sitting directly below the previous one or below U-Boot's own reservation. Growing it upwards at the same address runs into that memory and fails, so we end up in the else branch. If so, the 'common case' in the commit message mostly does not benefit. Copying the already-loaded bytes across in the else branch would make the saving apply in both cases. The comment above the loop still says "re-reading the full range from storage", so please update it too. For the test, imagemap_test_map_extend() only checks read_count, which is 2 whether the code reads the whole range or just the extra bytes. The mock already records last_off and last_size. Please can you assert that the second read is (64, 192), and add a variant using create_mock_loader_bl() with a block size larger than 1? That would show the new path is really used and the offsets are right for block media. Regards, Simon From sjg at chromium.org Thu Oct 1 08:59:52 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 16:59:52 +0100 Subject: [PATCH 04/11] boot: imagemap: free the reservation a replaced record owned In-Reply-To: References: Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > boot: imagemap: free the reservation a replaced record owned > > imagemap_record() overwrites an entry that already covers the same image > offset, including its lmb_reserved flag. When imagemap_map_to() replaces > a region that imagemap_map() had allocated from LMB, the reservation is > forgotten with the address that owned it, so imagemap_cleanup() walks a > table that no longer mentions it and the memory stays reserved for the > rest of the boot. > > Release the reservation before the entry is pointed at different memory. > > Fixes: 9b41c7dbee96 ("boot: add imagemap on-demand loading from storage") > Signed-off-by: Daniel Golle > > boot/imagemap.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > diff --git a/boot/imagemap.c b/boot/imagemap.c > @@ -114,12 +114,22 @@ imagemap_record(struct udevice *dev, loff_t img_offset, ulong size, > + /* > + * The entry is about to describe different memory, so give up > + * the reservation it owns while its address is still known. > + */ > + if (r->lmb_reserved && r->ram != ram) > + lmb_free(map_to_sysmem(r->ram), > + ALIGN(r->size, ARCH_DMA_MINALIGN), LMB_NONE); This fixes the leak but adds a lifetime problem. imagemap_map() has already given its caller a pointer into the old buffer, which used to stay valid until imagemap_cleanup(). Now the memory goes back to LMB while the caller may still hold the pointer, and a later lmb_alloc() can hand it out again, e.g. for the FDT or ramdisk relocation in bootm. One way to hit this is two FIT images sharing the same external data position, where only one has a load address. The first gets an imagemap buffer, which fit_image_get_data() returns via imagemap_lookup(). The second then calls imagemap_map_to() at the same offset and frees that buffer under the first. My suggestion is to stop imagemap_map_to() overwriting an LMB-owned entry. If the existing entry is lmb_reserved and the memory differs, append a new entry instead. imagemap_cleanup() still frees the reservation, so nothing leaks, and earlier pointers stay valid until then. What do you think? > diff --git a/boot/imagemap.c b/boot/imagemap.c > @@ -114,12 +114,22 @@ imagemap_record(struct udevice *dev, loff_t img_offset, ulong size, > + r->size = size; > + r->ram = ram; > + r->lmb_reserved = lmb_reserved; Just to check: if r->ram == ram, r->lmb_reserved is true and the new lmb_reserved is false, the flag is cleared and the reservation still leaks. That happens if a caller passes an imagemap-owned pointer as dst to imagemap_map_to(). Unlikely, but the fix is simple: keep the flag when the memory doesn't change. Also, r->size can shrink here, and the lmb_free() in imagemap_cleanup() then uses the smaller size. > diff --git a/boot/imagemap.c b/boot/imagemap.c > @@ -114,12 +114,22 @@ imagemap_record(struct udevice *dev, loff_t img_offset, ulong size, > /* Check for an existing entry at the same base that we can extend */ This comment no longer fits, since the loop now replaces the entry rather than extending it. The function comment also says the entry is updated only 'if the new size is larger', which the code has never done. Please can you update both? Please can you also add a test to test/boot/imagemap.c? imagemap_test_lmb_reserve() is a good model: call imagemap_map() then imagemap_map_to() at the same block-aligned offset, then check that the first buffer is no longer reserved after cleanup. Regards, Simon From sjg at chromium.org Thu Oct 1 08:59:49 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 16:59:49 +0100 Subject: [PATCH 03/11] cmd: ubi: unbind the block device when detaching UBI In-Reply-To: <57d688c070e2624e8d37a4e16a0f0d3ac3806410.1790626459.git.daniel@makrotopia.org> References: <57d688c070e2624e8d37a4e16a0f0d3ac3806410.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > cmd: ubi: unbind the block device when detaching UBI > > The ubi_blk device is parented to the MTD device UBI was attached to, > but ubi_detach() leaves it bound. After 'ubi part A; ubi detach; ubi > part B' the device still hangs off A's MTD while UBI sits on B, so the > driver-model tree describes a parent that is no longer in use and A's > MTD can no longer be removed. Reads happen to keep working only because > get_ubi_device() always returns ubi_devices[0]. > > Return the new device from ubi_bind(), remember it, and unbind it in > ubi_detach() so the next attach binds a fresh one under the right > parent. Tracking the device also replaces the scan of every UCLASS_BLK > device that was used to find it. > > Fixes: dec405d1653a ("cmd: ubi: create a ubi_blk device when attaching UBI") > Signed-off-by: Daniel Golle > > cmd/ubi.c | 73 +++++++++++++++++++++++++++++-------------------- > drivers/mtd/ubi/block.c | 4 ++- > include/ubi_uboot.h | 4 +-- > 3 files changed, 49 insertions(+), 32 deletions(-) > diff --git a/cmd/ubi.c b/cmd/ubi.c > @@ -650,6 +651,47 @@ static int ubi_set_skip_check(const char *volume, bool skip_check) > +#if CONFIG_IS_ENABLED(UBI_BLOCK) > +static struct udevice *ubi_blk_dev; > + > +static void ubi_blk_bind_once(void) > +{ > + struct udevice *parent; > + int ret; > + > + /* > + * A single ubi_blk device serves all volumes of the attached UBI > + * device, the volume being selected through the block descriptor's > + * hwpart. It is parented to the MTD device UBI sits on, so it must > + * not outlive the attach that created it. > + */ > + if (ubi_blk_dev) > + return; Driver model can free this device without cmd/ubi.c knowing. If anything unbinds the MTD parent (e.g. 'unbind' on the flash device), DM unbinds the ubi_blk child too, leaving ubi_blk_dev pointing at freed memory. The next ubi_detach() passes it to device_remove(), and the next ubi_part() returns early and never binds a new device. Patch 11 makes this easier to hit. With UTF_DM the DM tree is torn down after each test, so if imagemap_test_ubiblock() fails an assertion between ubi_part() and the final ubi_detach(), the next run's initial ubi_detach() uses the stale pointer. The UCLASS_BLK scan you are removing does not have this problem, since it can only find devices that still exist. Please can you keep the scan, and use it in ubi_blk_unbind() too to find the device to unbind? That still fixes the wrong-parent problem without global state. What do you think? > diff --git a/cmd/ubi.c b/cmd/ubi.c > @@ -650,6 +651,47 @@ static int ubi_set_skip_check(const char *volume, bool skip_check) > + device_remove(ubi_blk_dev, DM_REMOVE_NORMAL); > + device_unbind(ubi_blk_dev); > + ubi_blk_dev = NULL; Both return values are ignored. If device_remove() fails, device_unbind() returns -EINVAL for an activated device, and the pointer is cleared anyway, so the device stays bound under the old parent, which is the case this patch is trying to fix. Please at least log the error. Regards, Simon From sjg at chromium.org Thu Oct 1 09:00:40 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 17:00:40 +0100 Subject: [PATCH 11/11] test: boot: imagemap: reset driver-model state between tests In-Reply-To: <8fc90665aa0d615c4fe7fdabae57727666cac612.1790626459.git.daniel@makrotopia.org> References: <8fc90665aa0d615c4fe7fdabae57727666cac612.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > test: boot: imagemap: reset driver-model state between tests > > The tests bind and probe devices under dm_root() and the storage tests > depend on real driver-model state, but none of them asks for the DM > init and uninit the test framework provides. A test that fails before > imagemap_cleanup() therefore leaves its bound device behind, and the next > one trips over the name clash in device_bind_driver(). > > Pass UTF_DM throughout, and UTF_SCAN_FDT for the two tests that walk > device-tree partitions. Those two are also marked UTF_LIVE_TREE: they > drive mtd_probe_devices(), which cannot parse the partitions of a master > bound from a flat tree. I'm not sure about this. add_mtd_partitions_of() reads the partitions with the ofnode API (mtd_get_ofnode(), ofnode_find_subnode(), ofnode_for_each_subnode()), so I would expect it to work with a flat tree too. What actually fails in the flat-tree run? If the cause is something else, such as the static old_mtdparts / mtd_dev_list_updated() state in mtd_probe_devices() or MTD state left over from the live-tree run, please can you describe that instead? Otherwise UTF_LIVE_TREE just hides the problem. > > Fixes: 05c1fbbfa79f ("test: boot: add imagemap unit tests") > Signed-off-by: Daniel Golle > > test/boot/imagemap.c | 28 +++++++++++++++------------- > 1 file changed, 15 insertions(+), 13 deletions(-) > diff --git a/test/boot/imagemap.c b/test/boot/imagemap.c > @@ -649,5 +650,6 @@ static int imagemap_test_ubiblock(struct unit_test_state *uts) > -IMAGEMAP_TEST(imagemap_test_ubiblock, 0); > + > +IMAGEMAP_TEST(imagemap_test_ubiblock, UTF_DM | UTF_SCAN_FDT | UTF_LIVE_TREE); The motivation is a test that fails part-way, but for this test UTF_DM makes that case worse. If an assertion fails after ubi_part(), the test returns without calling ubi_detach(), and dm_test_post_run() then destroys every uclass. That frees the sand-nand device and its chips, which UBI still points to, as well as the ubi_blk device. nand_unregister() cannot delete the MTD either, since UBI holds a use count. Without UTF_DM, the leading ubi_detach() from patch 10 would clean up properly. Please can you make sure every failure after ubi_part() calls imagemap_cleanup(), free() and ubi_detach() (see my comment on patch 10), so the DM teardown never runs while UBI is still attached? Alternatively, keep this test out of UTF_DM. What do you think? > diff --git a/test/boot/imagemap.c b/test/boot/imagemap.c > @@ -571,7 +571,8 @@ static int imagemap_test_mtd_blk(struct unit_test_state *uts) > -IMAGEMAP_TEST(imagemap_test_mtd_blk, 0); > + > +IMAGEMAP_TEST(imagemap_test_mtd_blk, UTF_DM | UTF_SCAN_FDT | UTF_LIVE_TREE); Regards, Simon From sjg at chromium.org Thu Oct 1 09:02:27 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 17:02:27 +0100 Subject: [PATCH 07/11] boot: fit: unmap the load address after a storage read In-Reply-To: <9ecd2cb0a242f1dd110422e8554df8bcd091b655.1790626459.git.daniel@makrotopia.org> References: <9ecd2cb0a242f1dd110422e8554df8bcd091b655.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > boot: fit: unmap the load address after a storage read > > fit_image_load_storage() maps the load address to get a destination for > imagemap_map_to() and never unmaps it. The mapping is a no-op on most > architectures but not on sandbox, which is where the unit tests run. > > Pair the map_sysmem() with an unmap_sysmem() once the read is done. > > Fixes: 46d32e38ee4e ("boot: fit: support on-demand loading in fit_image_load()") > Signed-off-by: Daniel Golle > > boot/image-fit.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > The mapping is a no-op on most architectures but not on sandbox, which is where the unit tests run. Just FYI, on sandbox, unmap_physmem() returns early for anything inside emulated RAM (is_in_sandbox_mem()), and a FIT load address is always in emulated RAM, so in practice it is a no-op there too. I'm fine with adding the unmap for consistency (this is definitely an arcane part of sandbox!), but please can you reword this so it doesn't suggest the tests were leaking something? The Fixes: tag also feels a bit strong, but OK if you want it. > diff --git a/boot/image-fit.c b/boot/image-fit.c > @@ -2222,10 +2223,11 @@ static int fit_image_load_storage(struct bootm_headers *images, const void *fit, > mapped = imagemap_map_to(images->imagemap, data_off, data_sz, > dst); > + unmap_sysmem(dst); imagemap_map_to() saves dst in the region list through imagemap_record(), and fit_image_get_data() later hands that same pointer back through imagemap_lookup(). So this unmaps a pointer the imagemap still holds and keeps giving to callers, which only works because unmap_sysmem() does nothing here. If the unmap is meant to be correct, it should happen when the record is released (e.g. in imagemap_cleanup() for regions where lmb_reserved is false), or the region should store a physical address and map it on lookup. Otherwise I'd suggest leaving the code alone and adding a comment that the mapping lives as long as the imagemap record. What do you think? > diff --git a/boot/image-fit.c b/boot/image-fit.c > @@ -2190,6 +2190,7 @@ static int fit_image_load_storage(struct bootm_headers *images, const void *fit, > void *mapped; > + void *dst; There's no need to move this to function scope; it is only used inside the if() block. Sorry if I got that wrong in the previous review. Regards, Simon From sjg at chromium.org Thu Oct 1 09:02:35 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 17:02:35 +0100 Subject: [PATCH 10/11] test: boot: imagemap: detach UBI when the test is done In-Reply-To: <820120100ab98d856504b7edd2c5d86a09e2723c.1790626459.git.daniel@makrotopia.org> References: <820120100ab98d856504b7edd2c5d86a09e2723c.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > test: boot: imagemap: detach UBI when the test is done > > The UBI test attaches UBI to the sandbox NAND and leaves it attached, so > UBI still holds a reference to the MTD device when the test ends. Running > the suite a second time crashes in mtd_partitions_used(): the test calls > mtd_probe_devices(), which rebuilds the partition list of a master whose > partitions UBI is still using, and the walk then follows a freed entry. Just to check: mtd_del_parts() checks mtd_partitions_used() precisely so that it does not delete partitions still in use. If the walk follows a freed entry, something has already freed a partition while UBI held it. That looks like an MTD bug which 'ubi part nand2' followed by anything that reprobes could also hit. Please can you explain what frees the entry? If it is a real core bug, I suspect it should be fixed there, with this patch only tidying up the test. > > Detach UBI at the end of the test, and again at the start so a device > left behind by anything else is released before the partitions are > rebuilt. > > Fixes: 05c1fbbfa79f ("test: boot: add imagemap unit tests") > Signed-off-by: Daniel Golle > > test/boot/imagemap.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > diff --git a/test/boot/imagemap.c b/test/boot/imagemap.c > @@ -592,6 +592,13 @@ static int imagemap_test_ubiblock(struct unit_test_state *uts) > + /* > + * Release any device a previous run attached: UBI keeps a reference to > + * the MTD device, and mtd_probe_devices() would then rebuild the > + * partition list behind its back. > + */ > + ubi_detach(); This only helps if the device was left behind by an earlier run of this same test. Linker-list order puts imagemap_test_mtd_blk before this one, and it also calls mtd_probe_devices(), so if this test fails part-way, the next pass crashes in mtd_blk before this detach is reached. After the next patch it also acts on freed memory (see my comment on patch 3), and the 'ubi' global is left holding an MTD whose udevice has gone. > diff --git a/test/boot/imagemap.c b/test/boot/imagemap.c > @@ -638,6 +645,7 @@ static int imagemap_test_ubiblock(struct unit_test_state *uts) > > imagemap_cleanup(imdev); > free(wbuf); > + ubi_detach(); > > return 0; > } This is skipped whenever a ut_assert...() between ubi_part() and here fails, which is exactly the case the start-of-test detach is meant to cover, and wbuf leaks too. Please can you move the body into a helper and have the test function always detach afterwards, something like: static int imagemap_test_ubiblock(struct unit_test_state *uts) { int ret; ret = do_ubiblock_test(uts); ubi_detach(); return ret; } That keeps the teardown on every exit path, so you can drop the detach at the start. What do you think? Regards, Simon From sjg at chromium.org Thu Oct 1 09:02:40 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 17:02:40 +0100 Subject: [PATCH 08/11] boot: fit: keep the load message for RAM-backed images In-Reply-To: <65e01a6d030b93716174a0536d7a0c6b8edf1aca.1790626459.git.daniel@makrotopia.org> References: <65e01a6d030b93716174a0536d7a0c6b8edf1aca.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > boot: fit: keep the load message for RAM-backed images > > The "Loading ... from ... to ..." line is suppressed whenever > CONFIG_IMAGEMAP is built in and the source happens to equal the load > address. The test is a build-time one, so a board that enables imagemap > but boots a FIT from RAM loses the line as well. > > Suppress it only when an imagemap is actually in use, which is the one > case where the data was read straight to its load address and there is > no copy to report. > > Fixes: 46d32e38ee4e ("boot: fit: support on-demand loading in fit_image_load()") > Signed-off-by: Daniel Golle > > boot/image-fit.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > diff --git a/boot/image-fit.c b/boot/image-fit.c > @@ -2468,7 +2468,8 @@ int fit_image_load(struct bootm_headers *images, ulong addr, > - if (!CONFIG_IS_ENABLED(IMAGEMAP) || data != load) > + /* A storage-backed image was read straight to its load address */ > + if (!images->imagemap || data != load) Dropping the CONFIG_IS_ENABLED(IMAGEMAP) term means images->imagemap is read at runtime even when imagemap is not built, which isn't safe for every caller. spl_load_fit_image() declares 'struct bootm_headers images' on the stack and only sets 'verify', so in SPL (there is no SPL_IMAGEMAP, so the old expression was always true) this now tests uninitialised stack memory, and the message can disappear at random when data == load. The storage check further up keeps the build-time guard in front of the pointer test. Please can you do the same here: if (!CONFIG_IS_ENABLED(IMAGEMAP) || !images->imagemap || data != load) That keeps the runtime fix for RAM-backed boots with imagemap enabled, and lets the compiler drop the test when it is disabled. Separately, it would be worth zeroing 'images' in spl_load_fit_image() as vbe_common.c does, but that belongs in its own patch. Regards, Simon From sjg at chromium.org Thu Oct 1 09:02:45 2026 From: sjg at chromium.org (Simon Glass) Date: Thu, 1 Oct 2026 17:02:45 +0100 Subject: [PATCH 09/11] boot: bootm: release the imagemap on every failing exit In-Reply-To: <09c5c1f0cb1b49d571529f8c04191b8a24eb5505.1790626459.git.daniel@makrotopia.org> References: <09c5c1f0cb1b49d571529f8c04191b8a24eb5505.1790626459.git.daniel@makrotopia.org> Message-ID: Hi Daniel, On 2026-09-29T00:04:16, Daniel Golle wrote: > boot: bootm: release the imagemap on every failing exit > > Three error paths in bootm_run_states() return directly instead of > reaching the err label, so the imagemap device and the LMB reservations > its translation table holds survive a failed bootm: the missing OS boot > function, an unsupported subcommand, and any error carried out of the > earlier states. The first of those also left interrupts disabled. > > Route all three through err, which already releases the imagemap and > re-enables interrupts. > > Fixes: 46d32e38ee4e ("boot: fit: support on-demand loading in fit_image_load()") > Signed-off-by: Daniel Golle > > boot/bootm.c | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > The first of those also left interrupts disabled. Just to check: iflag is set as soon as BOOTM_STATE_LOADOS runs, so a later ramdisk/FDT failure or a failed subcommand also returned with interrupts disabled. All three paths had this problem, not just the first. > diff --git a/boot/bootm.c b/boot/bootm.c > @@ -1265,18 +1265,17 @@ int bootm_run_states(struct bootm_info *bmi, int states) > /* From now on, we need the OS boot function */ > if (ret) > - return ret; > + goto err; The err label does more than release resources. It also handles BOOTM_ERR_RESET / BOOTM_ERR_UNIMPLEMENTED, which was only meant for errors from bootm_load_os(). BOOTM_ERR_RESET is -1, and boot_ramdisk_high() returns -1 on any failure, so with this patch a 'ramdisk - allocation error' or 'in-place initrd alloc failed' now prints 'Resetting the board...' and calls reset_cpu() instead of returning the error. The same applies to the subcommand path below: on ARM, do_bootm_linux() returns -1 for BOOTM_STATE_OS_BD_T and BOOTM_STATE_OS_CMDLINE, so 'bootm bdt' would reset the board. This happens whether or not an imagemap is in use. Please can you keep the reset/unimplemented handling for the load_os path only? One way is to give that path its own label that falls through to the common cleanup. Another is to move the imagemap release and enable_interrupts() into a separate label after the BOOTM_ERR_* checks, and send these three exits there. What do you think? > diff --git a/boot/bootm.c b/boot/bootm.c > @@ -1318,7 +1317,7 @@ int bootm_run_states(struct bootm_info *bmi, int states) > if (ret) { > printf("subcommand failed (err=%d)\n", ret); > - return ret; > + goto err; > } See above. It would also be worth adding a sandbox test for a failing bootm subcommand with an imagemap attached, so this path is covered. Regards, Simon From john at phrozen.org Sat Oct 3 01:10:35 2026 From: john at phrozen.org (John Crispin) Date: Sat, 3 Oct 2026 10:10:35 +0200 Subject: REGRESSION: kernel: configure the kernel only when an input changed In-Reply-To: References: Message-ID: <3999f62f-ad1b-4f39-9b44-f0e3cdae568c@phrozen.org> On 02.10.26 21:00, Russell Senior wrote: > https://github.com/openwrt/openwrt/commit/e97e3f36bd5d48add83c5c7fba907600b12a653c > > This commit results in a regression on realtek switches (and perhaps > elsewhere), where a stale initramfs kernel gets included in a > subsequent squashfs image. See explanation here: > https://pastebin.com/xhHsTQng. Reverting this commit was tested and > fixes the problem. > > To reproduce, with a .config stub of: > > CONFIG_TARGET_realtek=y > CONFIG_TARGET_realtek_rtl931x=y > CONFIG_TARGET_realtek_rtl931x_DEVICE_zyxel_xs1930-12hp=y > > time make BUILD_LOG=1 IGNORE_ERRORS=m V=s target/linux/clean > time make BUILD_LOG=1 IGNORE_ERRORS=m V=s > $ ls -al bin/targets/realtek/rtl931x/*.bin > > time make -j1 BUILD_LOG=1 IGNORE_ERRORS=m V=s > $ ls -al bin/targets/realtek/rtl931x/*.bin > > The squashfs-sysupgrade.bin file size will jump by a few megabytes in > the second build and, more significantly, boots as an initramfs > instead of a squashfs due to the kernel-embdedded cpio rootfs. > thanks for reporting the regression should be fixed by 5d5ade6d162d219828900e8fa4faa274a19808f4 John From xuziyougm at gmail.com Sat Oct 3 10:45:24 2026 From: xuziyougm at gmail.com (Ziyou Xu) Date: Sun, 4 Oct 2026 01:45:24 +0800 Subject: Generic Linux PON framework RFC - looking for cross-vendor input Message-ID: <8db56e9c-11f4-4fc9-b1ac-b3638c78573e@gmail.com> Hi, We recently started an RFC discussion on netdev about whether Linux needs a small generic framework for PON devices: [RFC] net: towards a generic PON framework https://lore.kernel.org/netdev/20260926174601.1675-1-yhyxwgy at gmail.com/ The discussion started from existing work on Airoha AN7581/AN7583. That implementation already has working PON MAC/activation support, OMCI transport, GEM/T-CONT handling and an Ethernet datapath: https://github.com/pbs05/openwrt-pon-drivers https://github.com/pbs05/openwrt-pon-userspace There is also ongoing OpenWrt work for older EcoNet/Airoha PON hardware: https://github.com/openwrt/openwrt/pull/20104 The goal of the RFC is not to turn the current Airoha API into a generic Linux API. We are instead trying to determine which concepts, if any, are common between different PON implementations before one vendor's model gets frozen into a userspace ABI. Some of the questions currently being discussed are: - whether Linux needs a common PON device/line object; - how Ethernet service netdevs relate to GEM/LLID bearers; - where the boundary between TC/VLAN classification and PON bearer mapping should be; - how raw OMCI PDUs should cross the kernel/userspace boundary; - which GEM/T-CONT/LLID state belongs in generic code versus a hardware driver; - how activation/PLOAM/MPCP state should be exposed; - how fixed PON optics should interact with PHY, hwmon and NVMEM. The discussion has already shown that different working implementations make different choices about OMCI, activation and optical control, which is why another hardware family would be useful. We would especially like to hear from people working on Realtek, Lantiq/Intel/MaxLinear, Broadcom, or any other PON-capable SoCs. Even a partially working port is useful. In particular, information about how another PON MAC represents GEM/T-CONT/LLID resources, service classification, OMCI transport and activation state would help us identify which parts of the current Airoha designs are actually generic and which are hardware-specific. If you are working on xPON support in OpenWrt or Linux, please take a look at the RFC and join the discussion on netdev. Replies here pointing to existing code, vendor-open source trees or work-in-progress ports would also be very useful. Thanks, Ziyou Xu From john at phrozen.org Sat Oct 3 11:08:05 2026 From: john at phrozen.org (John Crispin) Date: Sat, 3 Oct 2026 20:08:05 +0200 Subject: Generic Linux PON framework RFC - looking for cross-vendor input In-Reply-To: <8db56e9c-11f4-4fc9-b1ac-b3638c78573e@gmail.com> References: <8db56e9c-11f4-4fc9-b1ac-b3638c78573e@gmail.com> Message-ID: <9a7a55bd-f4fe-48cc-b88e-2aa24f043924@phrozen.org> well. I guess that ship sailed ... I'll post https://github.com/blogic/linux/commits/main/ as a RFC within the next two days for context --> https://lore.kernel.org/all/0077ab02-2215-4015-9e74-eeb8c3de6b14 at phrozen.org/ On 03.10.26 19:45, Ziyou Xu wrote: > Hi, > > We recently started an RFC discussion on netdev about whether Linux > needs a small generic framework for PON devices: > > ? [RFC] net: towards a generic PON framework > ? https://lore.kernel.org/netdev/20260926174601.1675-1-yhyxwgy at gmail.com/ > > The discussion started from existing work on Airoha AN7581/AN7583. > That implementation already has working PON MAC/activation support, > OMCI transport, GEM/T-CONT handling and an Ethernet datapath: > > ? https://github.com/pbs05/openwrt-pon-drivers > ? https://github.com/pbs05/openwrt-pon-userspace > > There is also ongoing OpenWrt work for older EcoNet/Airoha PON > hardware: > > ? https://github.com/openwrt/openwrt/pull/20104 > > The goal of the RFC is not to turn the current Airoha API into a > generic Linux API. > > We are instead trying to determine which concepts, if any, are common > between different PON implementations before one vendor's model gets > frozen into a userspace ABI. > > Some of the questions currently being discussed are: > > ? - whether Linux needs a common PON device/line object; > ? - how Ethernet service netdevs relate to GEM/LLID bearers; > ? - where the boundary between TC/VLAN classification and PON bearer > ??? mapping should be; > ? - how raw OMCI PDUs should cross the kernel/userspace boundary; > ? - which GEM/T-CONT/LLID state belongs in generic code versus a > ??? hardware driver; > ? - how activation/PLOAM/MPCP state should be exposed; > ? - how fixed PON optics should interact with PHY, hwmon and NVMEM. > > The discussion has already shown that different working implementations make different choices about OMCI, activation and optical control, which is why another hardware family would be useful. > > We would especially like to hear from people working on Realtek, > Lantiq/Intel/MaxLinear, Broadcom, or any other PON-capable SoCs. > > Even a partially working port is useful. In particular, information > about how another PON MAC represents GEM/T-CONT/LLID resources, > service classification, OMCI transport and activation state would help > us identify which parts of the current Airoha designs are actually > generic and which are hardware-specific. > > If you are working on xPON support in OpenWrt or Linux, please take a > look at the RFC and join the discussion on netdev. Replies here > pointing to existing code, vendor-open source trees or work-in-progress > ports would also be very useful. > > Thanks, > Ziyou Xu > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel From michael at wyraz.de Sat Oct 3 13:44:47 2026 From: michael at wyraz.de (Michael Wyraz) Date: Sat, 3 Oct 2026 22:44:47 +0200 Subject: RFC: AT-controlled USB-Ethernet cellular modems: extend comgt-ncm or new netifd protocol? Message-ID: <4db61079-2bf4-4f0f-92c4-0d46698269de@wyraz.de> Hello, I'm porting a device with an ML352 LTE modem that exposes an RNDIS network interface and a separate AT control port. On this device, the IP address reported by AT+CGPADDR is also assigned to the host via RNDIS DHCP. After a cellular reconnection, that address can change while the host retains its old DHCP address. The network interface does not provide netifd with a usable link transition in this case. My current workaround polls the modem over AT, compares the addresses, and triggers a fresh DHCP discovery when they differ. I have observed the same stale-DHCP behaviour with a SIMCom A7672E in RNDIS mode, so this does not appear to be limited to the ML352. The current ML352 supervisor also configures the APN and roaming policy and reads registration and radio technology for status LEDs. I'm considering moving the modem and network lifecycle into a netifd protocol. Since comgt-ncm already supports AT command profiles and dynamic DHCP interfaces, would you prefer extending or refactoring it for AT-controlled RNDIS modems, or adding a separate protocol? The PDP/DHCP address comparison would only be enabled for modems that assign the PDP address to the host; NAT-based RNDIS modems need different handling. Thanks, Michael From felix.baumann at freifunk-aachen.de Sat Oct 3 16:22:25 2026 From: felix.baumann at freifunk-aachen.de (Felix Baumann) Date: Sun, 04 Oct 2026 01:22:25 +0200 Subject: =?US-ASCII?Q?Re=3A_RFC=3A_AT-controlled_USB-Ethernet_cellular_m?= =?US-ASCII?Q?odems=3A_extend_comgt-ncm_or_new_netifd_protocol=3F?= In-Reply-To: References: Message-ID: Hi, I'm confused. What are you suggesting: Aren't NCM and RNDIS mutually exclusive? RNDIS is about to be phased out. It's been deprecated for a while and a security nightmare. It ought to die. (my opinion, I'm not speaking for anyone on OpenWrt's behalf) Regards Felix Baumann From mrkiko.rs at gmail.com Sun Oct 4 01:15:42 2026 From: mrkiko.rs at gmail.com (Enrico Mioso) Date: Sun, 4 Oct 2026 10:15:42 +0200 Subject: RFC: AT-controlled USB-Ethernet cellular modems: extend comgt-ncm or new netifd protocol? In-Reply-To: References:

Message-ID: On Sun, Oct 04, 2026 at 01:22:25AM +0200, Felix Baumann via openwrt-devel wrote: > The sender domain has a DMARC Reject/Quarantine policy which disallows > sending mailing list messages using the original "From" header. > > To mitigate this problem, the original message has been wrapped > automatically by the mailing list software. > Date: Sun, 04 Oct 2026 01:22:25 +0200 > From: Felix Baumann > To: Michael Wyraz , Michael Wyraz via openwrt-devel > > Subject: Re: RFC: AT-controlled USB-Ethernet cellular modems: extend > comgt-ncm or new netifd protocol? > > Hi, > > I'm confused. What are you suggesting: > Aren't NCM and RNDIS mutually exclusive? > > RNDIS is about to be phased out. It's been deprecated for a while and a security nightmare. It ought to die. (my opinion, I'm not speaking for anyone on OpenWrt's behalf) Eheh, yeah. But we should also face reality and cellular modem firmwares. When you should work with a modem, changing it's firmware settings is not always possible or desirable, and you may find yourself stuck in a situation where it's not easy to set things as they where in the beginning. If I understand it correctly, what they are facing is a modem that works overRNDIS and handles things so that the DHCP state of the host may end up out of sync with the cellular network state, so they need to keep things in sync by: - polling the AT port or listening to the AT port to determine the current situation - re-triggering a DHCP lease in case it's needed. Thanks, Enrico > > > > Regards > Felix Baumann > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel at lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel From russell at personaltelco.net Sun Oct 4 01:39:55 2026 From: russell at personaltelco.net (Russell Senior) Date: Sun, 4 Oct 2026 01:39:55 -0700 Subject: REGRESSION: kernel: configure the kernel only when an input changed In-Reply-To: <3999f62f-ad1b-4f39-9b44-f0e3cdae568c@phrozen.org> References: <3999f62f-ad1b-4f39-9b44-f0e3cdae568c@phrozen.org> Message-ID: Seems fixed! Thank you! -- Russell Senior russell at personaltelco.net On Sat, Oct 3, 2026 at 1:10?AM John Crispin wrote: > > > > On 02.10.26 21:00, Russell Senior wrote: > > https://github.com/openwrt/openwrt/commit/e97e3f36bd5d48add83c5c7fba907600b12a653c > > > > This commit results in a regression on realtek switches (and perhaps > > elsewhere), where a stale initramfs kernel gets included in a > > subsequent squashfs image. See explanation here: > > https://pastebin.com/xhHsTQng. Reverting this commit was tested and > > fixes the problem. > > > > To reproduce, with a .config stub of: > > > > CONFIG_TARGET_realtek=y > > CONFIG_TARGET_realtek_rtl931x=y > > CONFIG_TARGET_realtek_rtl931x_DEVICE_zyxel_xs1930-12hp=y > > > > time make BUILD_LOG=1 IGNORE_ERRORS=m V=s target/linux/clean > > time make BUILD_LOG=1 IGNORE_ERRORS=m V=s > > $ ls -al bin/targets/realtek/rtl931x/*.bin > > > > time make -j1 BUILD_LOG=1 IGNORE_ERRORS=m V=s > > $ ls -al bin/targets/realtek/rtl931x/*.bin > > > > The squashfs-sysupgrade.bin file size will jump by a few megabytes in > > the second build and, more significantly, boots as an initramfs > > instead of a squashfs due to the kernel-embdedded cpio rootfs. > > > > > thanks for reporting the regression should be fixed by 5d5ade6d162d219828900e8fa4faa274a19808f4 > > John From michael at wyraz.de Sun Oct 4 01:04:18 2026 From: michael at wyraz.de (Michael Wyraz) Date: Sun, 4 Oct 2026 10:04:18 +0200 Subject: RFC: AT-controlled USB-Ethernet cellular modems: extend comgt-ncm or new netifd protocol? In-Reply-To: References:

Message-ID: <667f439e-21e2-4bc0-94f5-ff2768650f5d@wyraz.de> Hello Felix, yes, NCM and RNDIS are different USB data protocols. I did not mean to suggest using the NCM kernel driver for an RNDIS interface My question was about the userspace "comgt-ncm" which combines an AT control port, modem-specific AT command profiles, a USB network interface, and a netifd-managed DHCP child interface. The netifd script does not appear to depend on NCM itself, it's just named so. I was wondering whether that AT/control and DHCP logic should be reusable for other USB-Ethernet modem modes, rather than duplicating it in a new protocol. I understand the security concerns about RNDIS and would prefer another USB data mode if this modem offered one. So far, RNDIS is the only working data mode I have identified for this particular module. An integrated, fixed modem has a different threat model from arbitrary user-supplied USB devices, although its firmware still cannot be assumed trustworthy. I am not proposing to enable RNDIS by default or something. Kind regards, Michael. > Hi, > > I'm confused. What are you suggesting: > Aren't NCM and RNDIS mutually exclusive? > > RNDIS is about to be phased out. It's been deprecated for a while and a security nightmare. It ought to die. (my opinion, I'm not speaking for anyone on OpenWrt's behalf) > > > > Regards > Felix Baumann