From nobody Sat Jul 25 01:41:30 2026 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6AD6400E1A for ; Tue, 21 Jul 2026 02:52:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602343; cv=none; b=mCRURFcsoJ4b6Qr84ZZogBpCzP9AkwurfPxGzZKVgpB+Wa2zRqkWi0Yl9ZgPsKaD53u5stJHNm0fyUBdSQ4qJG3acnrv35MZXfygxWPBkf9gcZ4qBI13xsmfOrwKeJc55oYM+YyWvvpLpmg61WRVvFYFAD4kMXWd7VDmrqOC2g0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602343; c=relaxed/simple; bh=Mn8FcKbZ81xDVirfu+CjoQoPekNQzeKe0z8EvxMTayI=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=SV6mYnWRa/UDzjTe05/ywg2zuUsC2cgFilLbage3CG/rS+7/Rmy/uSpWsI2BRtHD9+X/RPekCLTZdJCO8Upmhq0LtVzCI5qGkL8VGrV/ndbk1z7uqF79MfLq9xAIUjmGddFSuw3g3PH7hEFW9ZOk40BHZFvzi32sCpewQdpXDjA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=lTPdFuig; arc=none smtp.client-ip=209.85.215.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="lTPdFuig" Received: by mail-pg1-f177.google.com with SMTP id 41be03b00d2f7-c9cf07d2df6so6794970a12.2 for ; Mon, 20 Jul 2026 19:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1784602341; x=1785207141; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tmYi4WVIxDVF63GoKUTqcWPie021wtL6weOItamcAaw=; b=lTPdFuigBLgTiLHdgzfLCfF/+n3R+6nhjqAIZCRNikJpF3Xz4nN0lia/AZFdZwcdnK Qo0an6GVaif82bfsTU7iW/+BMznG9kmm+gs91UsM7cOQ7IZPHP8wQt3i5j5Rzx+CbTUn qGcX2vkPxAvOeI+GHS6jKR+rRwQuw+mW+h8hVq9sn0e/GaF+YUedmSbcfsjVYw25MPQA XxSjJ71NmZ1uUbf5oDqkG3TLWXMwZM2f6Da4P/t3QaNgnXvw0t3N/UMisfERqjyGY/Jg GPq4M/8os4EFTiilRjf3K2kz1kDhz0soV8cUfKcO1vMNBgCBHrpcfsTVL4haRndUHETY ADYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784602341; x=1785207141; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tmYi4WVIxDVF63GoKUTqcWPie021wtL6weOItamcAaw=; b=PXpON0AhrKHdXc2F8260uIhWnPUa8P0RWIJ1B/7FWAYHAH0XzxYFVIcTWuO6jQEg9T DF+N64RYSMW0HJwil1UK/c2YmZ93Op4yYVXvpFjzGDjG0THvxth9GqvGiJMBRNCX76zH e0TBvQxt0SJV5aQxakBiwQJPBT/3uulgUuITSUsMGLJTkdBYsDE1Nx5D3yEspynwkmAx unoGQUhAhhgeCSpZNclJYrBDWHbYUTdDPC0U8U1wahJw/Eg+x2sSBlGPOEdZcNm1JZlx zOSFb26fGgCq0K6KZZr7nEwnMwoB/j0/SVq5HgZps3I8F7AARhT+UPXK3GQertxTpX3f Rj8g== X-Forwarded-Encrypted: i=1; AHgh+Rr6eTUV5K9DDKXADzAEvb5NLsWA/KVeLg5Kxuup8TUHhYaJJPtRdyBG9tLDCENgLvvPoII3henqQxXfnm4=@vger.kernel.org X-Gm-Message-State: AOJu0YzmRT11yNXqJ5hXz2ybqKQq32Z1xu9/p7MAFOV+s80QknMvRcsv U3GKc+/wnYPI/S/IStJaCMPtfVyy2HlisMI63J26JHnDShOZtOYMEroqgdD08YoFL00= X-Gm-Gg: AfdE7clskxlpmN7bvV1KebR9RqPnw+thlRhtNH66giCkF3D29AUKUjaVlwtDqusVClh H9QwLC2J15AKghC++F4T40qvWkaSTt7KW49NFm59lUccBZNsg+bhV17Rv8sh+dPzri8p1Rw2wiZ hg3TXQZinGoyNCnobmHc9qJ5/XEk2030XhS9IQNHRV4BXzfrlFUZjNkcQdQYlGGz/j9haVrCIFB zKPaHTjw/nnXnwtj9mi2EDNDiavbyY6f/bDlAM8gnHxUXwmHY9VfcfmR6rdJX4CI7LNZpfHrjde edC3I/NkCnsx1Ez2DAmnd4402VvtnjWZHCCyXixrlABqZIYhUTgTG4z+H8Hv2MeV708pdU1s039 W0TdYgja4fe9pJNWmu/xzor5lf9671BUD65KrTXEJrfshwagzFWsJHwNaNb5UsBxRDf22+iT7Px rjmMJh X-Received: by 2002:a05:6a20:12c8:b0:3bf:6c08:4ec1 with SMTP id adf61e73a8af0-3c3ad93dd28mr17276728637.54.1784602340973; Mon, 20 Jul 2026 19:52:20 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1de301sm41167294eec.24.2026.07.20.19.52.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 19:52:20 -0700 (PDT) From: Abdurrahman Hussain Date: Mon, 20 Jul 2026 19:52:15 -0700 Subject: [PATCH RFC 1/4] of: incrementally update /aliases lookup on reconfig notifications Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260720-nh-of-alias-overlay-v1-1-27da6848dd84@nexthop.ai> References: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> In-Reply-To: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> To: Rob Herring , Saravana Kannan Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1784602339; l=15117; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=Mn8FcKbZ81xDVirfu+CjoQoPekNQzeKe0z8EvxMTayI=; b=lybnOtG/2/+TKIgC1KQMqXcO1LBS7/g6XnpasXPjIRk1CXVlsDMDz6uNOQ2yAD0SsZmuYRPE8 /g1YYiXO9tsB6dvdNnNqIok3NN3/7mxd4mDz74/CJiVSQVaSMR37GwD X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= /aliases entries added by a device-tree overlay are stored in the live tree but never enter the global aliases_lookup list that of_alias_scan() builds at boot. As a result, of_alias_get_id() returns -ENODEV for aliases declared inside overlays, and any driver that relies on alias-based numbering (i2c-xiic, spi, tty, mmc, ...) silently loses its pinned id and falls back to auto-assignment. Fix by registering an internal OF reconfig notifier from of_core_init() that mirrors /aliases changes into aliases_lookup: OF_RECONFIG_ADD_PROPERTY -> of_alias_create() OF_RECONFIG_REMOVE_PROPERTY -> of_alias_destroy() OF_RECONFIG_UPDATE_PROPERTY -> destroy + create OF_RECONFIG_ATTACH_NODE -> scan all properties (defensive) OF_RECONFIG_DETACH_NODE -> forget all properties (defensive) The reconfig notifier chain fires from both direct changesets and overlay apply/revert, so the same code path covers runtime dt modifications and overlay-declared aliases without any overlay- specific hook in drivers/of/overlay.c. Grant Likely suggested this shape on Geert Uytterhoeven's 2015 RFC [1]; Geert's original hook was in dynamic.c directly. Match the /aliases target node structurally (name =3D=3D "aliases" and parent =3D=3D root) rather than by pointer against the of_aliases global. A system with no boot-time /aliases has of_aliases =3D=3D NULL, so an overlay that creates /aliases from scratch would otherwise be missed from the first ATTACH_NODE onward. ATTACH/DETACH also update of_aliases lazily (with of_node_get/put) so subsequent consumers see it. Overlays build the node up empty and add properties via separate ADD_PROPERTY events; other callers of of_attach_node() are allowed to attach a fully-populated node in one shot. Handle both shapes by scanning the node's properties on ATTACH_NODE and forgetting them on DETACH_NODE. Overlay-driven flows still receive per-property events and remain correct. Factor the per-property loop body of of_alias_scan() into of_alias_create() so the boot-time scan and the runtime notifier share one code path. Owned (runtime) entries kstrdup the alias name and hold an of_node_get() reference on the target so the alias_prop survives the property that spawned it =E2=80=94 required for the overlay revert path where the source property is freed before we get a chance to see it drop. A one-bit @owned flag on struct alias_prop distinguishes kmalloc'd entries from memblock-backed ones so the destroy path kfree()s the right ones. The destroy path unlinks matching entries regardless of ownership (freeing storage only for owned ones) so an overlay UPDATE against a boot-time alias leaves at most one entry per stem+id. This addresses the allocator-mismatch worry Grant flagged on the 2015 series [2] and also the duplicate-mapping side effect that would otherwise leak through. Serialize aliases_lookup on a dedicated aliases_mutex: readers (of_alias_get_id, of_alias_get_highest_id) and the reconfig notifier both hold it around every access. Boot-time of_alias_scan() runs single-threaded during init and stays lockless. This is preferable to piggy-backing on of_mutex because the reconfig notifier is called both under of_mutex (overlay apply path) and outside of it (direct of_add_property() path from dynamic.c), so a nested acquisition would deadlock on some callers. Validate the property value before feeding it to of_find_node_by_path(): pp->value must be non-empty and null-terminated within pp->length. An overlay that hasn't been through /aliases fixup can otherwise present a fragment-internal string that isn't a valid live-tree path or a malformed non-terminated value, and of_find_node_by_path() derefs it as a C string =E2=80=94 an OOB read on the malformed case. Naming builds on Geert's original series: - "of: Extract of_alias_create()" [3] - "of: Add of_alias_destroy()" [4] - "of/dynamic: Update list of aliases on aliases changes" [5] Link: https://lore.kernel.org/lkml/1435675876-2159-1-git-send-email-geert+r= enesas@glider.be/ [1] Link: https://lore.kernel.org/lkml/20150630172131.D4E6CC4041A@trevor.secret= lab.ca/ [2] Link: https://lore.kernel.org/lkml/1435675876-2159-2-git-send-email-geert+r= enesas@glider.be/ [3] Link: https://lore.kernel.org/lkml/1435675876-2159-3-git-send-email-geert+r= enesas@glider.be/ [4] Link: https://lore.kernel.org/lkml/1435675876-2159-4-git-send-email-geert+r= enesas@glider.be/ [5] Signed-off-by: Abdurrahman Hussain --- drivers/of/base.c | 271 +++++++++++++++++++++++++++++++++++++++++---= ---- drivers/of/of_private.h | 7 ++ 2 files changed, 238 insertions(+), 40 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 6e7a42dedad3..2695c5f8bb93 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -1915,6 +1915,231 @@ static void of_alias_add(struct alias_prop *ap, str= uct device_node *np, ap->alias, ap->stem, ap->id, np); } =20 +/* + * Serializes aliases_lookup and of_aliases across boot-time scan, + * runtime notifier updates, and readers. of_alias_get_id() and + * of_alias_get_highest_id() acquire this before walking the list; the + * OF reconfig notifier below acquires it around each mutation. + * of_alias_scan() runs single-threaded from of_core_init() and skips + * the lock, but any code path that reads or writes aliases_lookup + * outside init must hold it. + */ +static DEFINE_MUTEX(aliases_mutex); + +/* + * Build an alias_prop for @pp using @dt_alloc as the storage allocator + * and add it to aliases_lookup. @owned is stored on the entry so the + * matching destroy path knows whether the alias_prop is a kmalloc'd + * struct that must be kfree()d (with a paired of_node_put on the + * target and kfree on the kstrdup'd alias name) or a memblock/ + * dt_alloc'd struct that must be left alone. + * + * Callers other than of_alias_scan() must hold @aliases_mutex. + * + * Skips pseudo-properties (name, phandle, ...), malformed property + * values (empty or not null-terminated within pp->length), and alias + * names not ending in a numeric id. + */ +static void of_alias_create(const struct property *pp, + void *(*dt_alloc)(u64 size, u64 align), + bool owned) +{ + const char *start =3D pp->name; + const char *end; + struct device_node *np; + struct alias_prop *ap; + const char *dup; + int id, len; + + if (is_pseudo_property(pp->name)) + return; + + /* + * pp->value must be a non-empty, null-terminated string within + * pp->length. of_find_node_by_path() derefs it as a C string, so + * a missing terminator would cause an OOB read. + */ + if (!pp->value || pp->length < 2 || + strnlen(pp->value, pp->length) >=3D pp->length) + return; + + np =3D of_find_node_by_path(pp->value); + if (!np) + return; + + end =3D start + strlen(start); + while (end > start && isdigit(*(end - 1))) + end--; + len =3D end - start; + if (len =3D=3D 0) + goto out_put; + + if (kstrtoint(end, 10, &id) < 0) + goto out_put; + + ap =3D dt_alloc(sizeof(*ap) + len + 1, __alignof__(*ap)); + if (!ap) + goto out_put; + memset(ap, 0, sizeof(*ap) + len + 1); + + /* + * For runtime entries, kstrdup the alias name so the alias_prop + * doesn't depend on pp->name remaining valid =E2=80=94 an overlay revert + * frees the source property. Boot-time entries point into the + * FDT, which is never freed. + */ + if (owned) { + dup =3D kstrdup(pp->name, GFP_KERNEL); + if (!dup) { + kfree(ap); + goto out_put; + } + } else { + dup =3D start; + } + ap->alias =3D dup; + ap->owned =3D owned; + of_alias_add(ap, np, id, start, len); + return; + +out_put: + if (owned) + of_node_put(np); +} + +/* + * Reverse of of_alias_create() for owned entries: unlink and free the + * matching alias_prop and drop the reference it holds on the target + * node. For boot-time entries (owned=3Dfalse) it unlinks only =E2=80=94 t= he + * struct and the alias name live in memblock and are never freed =E2=80= =94 + * which prevents an overlay-driven UPDATE_PROPERTY against a boot-time + * alias from leaving stale duplicates in aliases_lookup. + * + * Callers must hold @aliases_mutex. + */ +static void of_alias_destroy(const char *name) +{ + struct alias_prop *ap, *tmp; + + list_for_each_entry_safe(ap, tmp, &aliases_lookup, link) { + if (strcmp(ap->alias, name) !=3D 0) + continue; + list_del(&ap->link); + if (ap->owned) { + of_node_put(ap->np); + kfree(ap->alias); + kfree(ap); + } + return; + } +} + +static void *alias_alloc(u64 size, u64 align) +{ + return kzalloc(size, GFP_KERNEL); +} + +/* Scan every property of @aliases and mirror it into aliases_lookup. */ +static void of_alias_node_scan(struct device_node *aliases) +{ + struct property *pp; + + for_each_property_of_node(aliases, pp) + of_alias_create(pp, alias_alloc, true); +} + +/* Reverse: destroy every alias_prop backed by a property of @aliases. */ +static void of_alias_node_forget(struct device_node *aliases) +{ + struct property *pp; + + for_each_property_of_node(aliases, pp) + of_alias_destroy(pp->name); +} + +/* + * OF reconfig notifier that mirrors /aliases property changes into + * aliases_lookup. Fires on both direct changesets and overlay + * apply/revert, so of_alias_get_id() returns the right id for aliases + * declared inside an overlay. + */ +static int of_aliases_reconfig_notifier(struct notifier_block *nb, + unsigned long action, void *arg) +{ + struct of_reconfig_data *rd =3D arg; + + /* + * Match /aliases structurally (name + root-parent) rather than by + * pointer against the of_aliases global =E2=80=94 a system with no + * boot-time /aliases (of_aliases =3D=3D NULL) can still acquire one + * from an overlay, and we must track its properties from the + * first ATTACH_NODE onward. + */ + if (!rd->dn || !rd->dn->parent || + !of_node_is_root(rd->dn->parent) || + !of_node_name_eq(rd->dn, "aliases")) + return NOTIFY_DONE; + + mutex_lock(&aliases_mutex); + switch (action) { + case OF_RECONFIG_ATTACH_NODE: + /* + * Overlays build the node up empty and add properties via + * separate ADD_PROPERTY events, but the reconfig API also + * permits attaching a fully-populated node in one shot =E2=80=94 + * scan defensively so pre-populated aliases aren't lost. + */ + of_alias_node_scan(rd->dn); + if (!of_aliases) + of_aliases =3D of_node_get(rd->dn); + break; + case OF_RECONFIG_DETACH_NODE: + /* + * Symmetric with ATTACH_NODE: some callers detach without + * emitting per-property REMOVE events first, so drop every + * alias_prop backed by this node's properties before it + * disappears. + */ + of_alias_node_forget(rd->dn); + if (of_aliases =3D=3D rd->dn) { + of_node_put(of_aliases); + of_aliases =3D NULL; + } + break; + case OF_RECONFIG_ADD_PROPERTY: + of_alias_create(rd->prop, alias_alloc, true); + break; + case OF_RECONFIG_REMOVE_PROPERTY: + of_alias_destroy(rd->prop->name); + break; + case OF_RECONFIG_UPDATE_PROPERTY: + if (rd->old_prop) + of_alias_destroy(rd->old_prop->name); + of_alias_create(rd->prop, alias_alloc, true); + break; + default: + break; + } + mutex_unlock(&aliases_mutex); + return NOTIFY_OK; +} + +static struct notifier_block of_aliases_nb =3D { + .notifier_call =3D of_aliases_reconfig_notifier, +}; + +static int __init of_aliases_reconfig_init(void) +{ + return of_reconfig_notifier_register(&of_aliases_nb); +} + +/* + * of_alias_scan() runs from of_core_init() (core_initcall), so hook the + * reconfig notifier one initcall level later to guarantee the initial + * static scan is complete before any dynamic tracking begins. + */ +core_initcall_sync(of_aliases_reconfig_init); + /** * of_alias_scan - Scan all properties of the 'aliases' node * @dt_alloc: An allocator that provides a virtual address to memory @@ -1950,42 +2175,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 = align)) if (!of_aliases) return; =20 - for_each_property_of_node(of_aliases, pp) { - const char *start =3D pp->name; - const char *end =3D start + strlen(start); - struct device_node *np; - struct alias_prop *ap; - int id, len; - - /* Skip those we do not want to proceed */ - if (is_pseudo_property(pp->name)) - continue; - - np =3D of_find_node_by_path(pp->value); - if (!np) - continue; - - /* walk the alias backwards to extract the id and work out - * the 'stem' string */ - while (isdigit(*(end-1)) && end > start) - end--; - len =3D end - start; - - if (kstrtoint(end, 10, &id) < 0) { - of_node_put(np); - continue; - } - - /* Allocate an alias_prop with enough space for the stem */ - ap =3D dt_alloc(sizeof(*ap) + len + 1, __alignof__(*ap)); - if (!ap) { - of_node_put(np); - continue; - } - memset(ap, 0, sizeof(*ap) + len + 1); - ap->alias =3D start; - of_alias_add(ap, np, id, start, len); - } + for_each_property_of_node(of_aliases, pp) + of_alias_create(pp, dt_alloc, false); } =20 /** @@ -2003,7 +2194,7 @@ int of_alias_get_id(const struct device_node *np, con= st char *stem) struct alias_prop *app; int id =3D -ENODEV; =20 - mutex_lock(&of_mutex); + mutex_lock(&aliases_mutex); list_for_each_entry(app, &aliases_lookup, link) { if (strcmp(app->stem, stem) !=3D 0) continue; @@ -2013,7 +2204,7 @@ int of_alias_get_id(const struct device_node *np, con= st char *stem) break; } } - mutex_unlock(&of_mutex); + mutex_unlock(&aliases_mutex); =20 return id; } @@ -2031,7 +2222,7 @@ int of_alias_get_highest_id(const char *stem) struct alias_prop *app; int id =3D -ENODEV; =20 - mutex_lock(&of_mutex); + mutex_lock(&aliases_mutex); list_for_each_entry(app, &aliases_lookup, link) { if (strcmp(app->stem, stem) !=3D 0) continue; @@ -2039,7 +2230,7 @@ int of_alias_get_highest_id(const char *stem) if (app->id > id) id =3D app->id; } - mutex_unlock(&of_mutex); + mutex_unlock(&aliases_mutex); =20 return id; } diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h index 0ae16da066e2..9d16765ae2c3 100644 --- a/drivers/of/of_private.h +++ b/drivers/of/of_private.h @@ -17,6 +17,12 @@ * @alias: Alias property name * @np: Pointer to device_node that the alias stands for * @id: Index value from end of alias name + * @owned: True if @alias was kstrdup'd and @np was of_node_get'd on + * insertion (overlay-time entries). False for entries built + * by of_alias_scan() at boot, where @alias points into the + * FDT and @np is an unreferenced pointer. The removal path + * uses this flag to decide whether it must kfree(@alias), + * of_node_put(@np), and kfree(the struct itself). * @stem: Alias string without the index * * The structure represents one alias property of 'aliases' node as @@ -27,6 +33,7 @@ struct alias_prop { const char *alias; struct device_node *np; int id; + bool owned; char stem[]; }; =20 --=20 2.54.0 From nobody Sat Jul 25 01:41:30 2026 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82DCB401A37 for ; Tue, 21 Jul 2026 02:52:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602343; cv=none; b=K5jKKjH6gw6e3FuEO7F0QqymiBPNxHcFUkgPGHbI76LFRRMs3azQqERT14dxWupgljuyWYP16eezxQ03qf41iNq8foep6dPk+iI0HvqWcbKHyESvh96haRQ57ywpesO7zITH4Mhnr161t5flLl2mW3PMiMZAxtHzoCizqs/Cujs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602343; c=relaxed/simple; bh=R6tBpLfkSYlFbeXQtoe6ybjEQWYkSemCib35gwY2h1U=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=dBJhWCwidh6toQLAwFeMF2K9jAfyQL8Jffn585PH69OhkwQNWu4P0jUQcCzzSn7z0N7eV2LWRcloZekH1hHj3hQIMAVAAxJsCcrNfR46NJZ8874umtwTkMmkfs/gcte56ikfan9rH5xfLjtP/trPZQAOF+WyJMXpMforPsYghlk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=AXEMFLEg; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="AXEMFLEg" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2cacf197759so122236635ad.2 for ; Mon, 20 Jul 2026 19:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1784602342; x=1785207142; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Jb3SzunVzCrAW1kpVHD7vkFwItBmsZgciNXBopwYDGc=; b=AXEMFLEg9jxaPgwL9qANAkAZchYTbcq4zUTwYLVN4Esy67WOvvrvYDB17RRV3n2KNm Skk+8sa8fYxeZvOXVMNsPT/I9pGcWHydnEdHVkbGVCSzb3xdrscRWBltxBfcV+EsZ8r+ f2my5y41gAcJAlSA1lo0G9YLVf5bJd7pJlEpjA3Z2vjL2e6zGoxykd14B2+fnFoCz9sb kBm9BXlYMOa+6Us1BIeDzfHTGcH+5JpstkS9j76YbtKw69EKnvCeauBZqk2XR0TvxbTt m4GjxKeY8DDkmTniV0WvPAzcOJregB3/w8rgrbeVq20B2nMosufTH5faXd4iTUtc7K9j l1nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784602342; x=1785207142; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Jb3SzunVzCrAW1kpVHD7vkFwItBmsZgciNXBopwYDGc=; b=ZIQFyQi1gE5b0k9V+eK0oOhdhmSISNRv5gUn2XzjQWuR2TgJ8JfgnCFdJaaJvCNdp4 H9nqYjDaTvn1I65hdW/kA+gNBAwVs9vNe83aMOfkfU0epmc5TCg0fNkH4aCF+jCEAHw6 nacQBhV4ycOCaYG9AaCn6qa4J7q0Bnh9v343OjvKcWWiPqzjYuRY+FEQBBBJB4Zj0Lz3 KJwJSieeJNUZ16CDNuxygb4kcfuFIYNY9/6+vXN+5F9eAIcmu2sdYXFsQNY8EeuFurYW sOR8ILIVcQ5OlMijLj5V6WrZ+Hqu0uiWFii1Si/Yl0c61G/Zl03dfnG82smmnGARBqhJ Jf7w== X-Forwarded-Encrypted: i=1; AHgh+RpVEwDYB33iJR24j/sE7Kryert9/mSKnyLxaYhJwmGeE8Y5PLoj8sum+0W8L1RoFiVyP09XmXH2ZfPBJ8w=@vger.kernel.org X-Gm-Message-State: AOJu0YwCQjXgdZ8RJsAQaGX9KxMdU+CXsfM9wAcN73m1sTlIVH9Ik1fi 0St1CiJki+9JhJZA27dL9Q+TU7mH4PGRyjstyBy3aFymhjXIWVykHuAcpwn2UrLgu9JoQ1OjCbM jcaGRupw= X-Gm-Gg: AfdE7ckzQrsILVulmH4gCZB2pMJdXd5yraX9i9PjSeskhW5xPr/npKJfW1cd2zjj+FB b3KWftMOWXBvwhiLJrl/LCSXW9GAOZf5FI73ucEc10+X2AyR0QC+PE/tSzLsY+obSpEeLFIWnHT BdH0B3W0JHnLor4OLp9A0QiNc5YjOtnHgmr6xoncqjx0Wzn5fpJJCSoGNgvazEHUykKnRpToh2T kxjU88OZPMIBDILN2pJEcOrYGwAN6+HDQ0wFvKPeRtEZK6Xx6ohie+C0X44KSy33q8TUZ6lszkP 6KVo+riHn4TAeHMxBh4fJMSgVwZei+yqDHmpXf+dPUb7HarFeyG8rBLeXvta3p6r4fyFauog7+T 5tKLrzZxIsnmVWu7CQD4YAaQj4h5VVExv4tRFza0a4/8ayyaO92y5dhQjLidRYBAxDY9DGasmha tkvM906DBTCwAgewM= X-Received: by 2002:a05:6a20:9148:b0:3a8:9dd:75d5 with SMTP id adf61e73a8af0-3c3ad66833dmr19084843637.24.1784602341768; Mon, 20 Jul 2026 19:52:21 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1de301sm41167294eec.24.2026.07.20.19.52.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 19:52:21 -0700 (PDT) From: Abdurrahman Hussain Date: Mon, 20 Jul 2026 19:52:16 -0700 Subject: [PATCH RFC 2/4] of/overlay: look up absolute target-paths absolutely Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260720-nh-of-alias-overlay-v1-2-27da6848dd84@nexthop.ai> References: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> In-Reply-To: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> To: Rob Herring , Saravana Kannan Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1784602339; l=3039; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=R6tBpLfkSYlFbeXQtoe6ybjEQWYkSemCib35gwY2h1U=; b=yt2GfxHQrIY8Z2eAvW7m7IeX9EvWMV3QYggBALOn9yd+GDXFOG10OiNvY9UWpmha1XDchmGaN 7GsZEFB/f41CKuTeCmoZ5Miuhsl1fZqU2vZ/ywngYvV5GksQYMadug0 X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= When of_overlay_fdt_apply() is called with a non-NULL target base, find_target() currently concatenates the base's full path with every fragment's target-path via "%pOF%s" =E2=80=94 so target-path=3D"" resolves = to the base itself (the intended common case), but target-path=3D"/foo" resolves to "/foo" (never the DT root) and target-path=3D"/" to "/" (never a valid node at all). That makes it impossible for a two-fragment overlay to modify one subtree under the base and one node at the DT root =E2=80=94 a shape that arises naturally when a PCI-attached device wants to declare its peripherals under dev_of_node(&pdev->dev) AND add /aliases entries so alias-aware drivers (i2c-xiic, spi, tty, ...) can pin bus numbers. Treat target-path as absolute whenever it is non-empty. An empty target-path continues to mean "the target base itself", preserving the existing shape used by drivers/misc/lan966x_pci.c and its dtso (the only in-tree of_overlay_fdt_apply() caller today that passes a non-NULL base). Signed-off-by: Abdurrahman Hussain --- drivers/of/overlay.c | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c index 08d5351746be..654a70d5cb07 100644 --- a/drivers/of/overlay.c +++ b/drivers/of/overlay.c @@ -693,7 +693,6 @@ static struct device_node *find_target(const struct dev= ice_node *info_node, const struct device_node *target_base) { struct device_node *node; - char *target_path; const char *path; u32 val; int ret; @@ -709,23 +708,22 @@ static struct device_node *find_target(const struct d= evice_node *info_node, =20 ret =3D of_property_read_string(info_node, "target-path", &path); if (!ret) { - if (target_base) { - target_path =3D kasprintf(GFP_KERNEL, "%pOF%s", target_base, path); - if (!target_path) - return NULL; - node =3D of_find_node_by_path(target_path); - if (!node) { - pr_err("find target, node: %pOF, path '%s' not found\n", - info_node, target_path); - } - kfree(target_path); - } else { - node =3D of_find_node_by_path(path); - if (!node) { - pr_err("find target, node: %pOF, path '%s' not found\n", - info_node, path); - } - } + /* + * With a non-NULL @target_base, an empty target-path means + * "the target base itself" =E2=80=94 this is the common + * of_overlay_fdt_apply(..., base) form used by e.g. the + * LAN966x PCI overlay. Any other target-path is looked up + * absolutely, so overlays that also need to reach the DT + * root (e.g. to add /aliases entries alongside a base- + * relative fragment) can do so with target-path=3D"/aliases". + */ + if (target_base && path[0] =3D=3D '\0') + return of_node_get((struct device_node *)target_base); + + node =3D of_find_node_by_path(path); + if (!node) + pr_err("find target, node: %pOF, path '%s' not found\n", + info_node, path); return node; } =20 --=20 2.54.0 From nobody Sat Jul 25 01:41:30 2026 Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4251940245F for ; Tue, 21 Jul 2026 02:52:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602344; cv=none; b=LhcFADdBlBaZ1mTNBPbRO/5nSbGRhleIuQFZRMY4zqVcOuVwDRCFdABGaXqthqQwD3m8sFVTU7pzuUhOyO7WHj0QSlF/3APfAGIHn6ULTYIH/ZpevVgofnNC2LirpZp94h0Y0T3NS+jqii3iF7dIsZ0zntTtffqRpMogieltg5s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602344; c=relaxed/simple; bh=iGWdJ4L5f5PhXUJWpbe2stIHXNaMh0PyRFQdLM6T2KQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=EXvUDZYs+EPhpdEU7LllC7csHudxGCba343jCMtpOEzK9YCTvpicckbvuv3eQPNBKTbHIdqMeueh91JlYGioj6px7CcdKARVU491wq/X/5+HhbULpfBHMIO6H61u0DcEKnsVuLDoS+gpvyngGHzk4sPi/rT2Y3gEXD1m2w8ASqo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=fV+OO7pe; arc=none smtp.client-ip=209.85.215.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="fV+OO7pe" Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-c96c92c0980so4913491a12.3 for ; Mon, 20 Jul 2026 19:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1784602342; x=1785207142; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=UGMP5Dip13MgtJqhnlj6cH7hgyPXYLqPSL+6bi+f51M=; b=fV+OO7peizJMNrkT7ZPq8Bw1JVqf7DbABiR0vkQ+tFgbcHmPeOsBZeQ7tG59N5ljmR 1ZMiUfCtVHrPUo4qiXtCHDZxtQYywNNiI4cINnECmKlskia3WA+3Y2wftXlFPbiNizXq e33ZgqEQ6KSbH+Zo6F/0zilGfWASwxV0lcYISeG9uQabEHLRf3AJPnCYAdHfW9DykA5U oivfjLkbyovj+OXDiARx4N4wW7gDVDixn/omrtKEuZ12GdxkhAhfbOKGc8U0NWJ+UnTs rUv3fMnBJhWScpErWCGO2bUrm74kXz1UX/c/EZeXqEK4FlyzROT8LoWC4aipKvTPT1zR KL2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784602342; x=1785207142; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=UGMP5Dip13MgtJqhnlj6cH7hgyPXYLqPSL+6bi+f51M=; b=AGmQd7fCIGWUt3FwI9pjccCoxU3qdicqGAvCV612rN5WFXYK3YYS71F+VUw3hsZXy1 VtIyuvgD7w+hKUVPQHwbAnk34K9wOO2MArDoCvlIeV7wyBUQGIb0fOl8K4+CmajSMj/K LOP3PpWWXvxGMCgZIWCarNAgVLAi+SM+NqUBCWzR76FI3JTwOn+LvEV6DOs+RVea9sMA Kxefw7WcYOiuy7MhbFMG9UgTAp9deFLRm+T6P5VCrjgySSCGFzhLGicMx3fnMtogq4dh 57i+rSDZtfuLIiO7l4aePvGK+hijbr64JiECAUq+FGe2hB9+ODVCfCoaMV/mcaJmtw0l vomg== X-Forwarded-Encrypted: i=1; AHgh+RqrIU59IeyCyYP9kctnoiYXsUwhSv7cWjyZ4e33wQ2CxVrDcL9vBXYbAkckhyLQvY47JnqKjtubrxKzwFA=@vger.kernel.org X-Gm-Message-State: AOJu0YwxM+Xh6jN0lc4FjyByVTTJbYDxPKhISvWkdc0z3fkZ6q024M0U ezBSnaaD9SNG9H438plUyO1FVO97K9l0NqNbnyDF1aNRuiDNpTm4DcQwUjPJ6kIBHv0= X-Gm-Gg: AfdE7cnjoFwJkqzVeOSrf7XsG87cb8hvFQfbzvlvW7GaV1DJqssKEgUb4zWVdSGVMtT rCJIen7hb0SM53SiNXQBg5YzrD53nBYdTSAmTamjMidKIAUkH2WjbIlTeV/rHlHKiguaJ8kEza5 EFN5OlCFJX6K2rXxCbPnW+UjGmbU6A/LUdY2p8Bz4lEBr7UedZ1BU93p/Mm3ke9qb45Q0lMobFC dG1haZNTyL6Eyg5b2ck3JMr+jbSiwu6Rx6Qxj5IBD4eDPIMjLcqFMrpZtHsL1imRpwR5bnZ8GYw K6SDpGH7ZHvI4o9LKa3+1VAM5iSLt+FbbK2emjKsxV3hV+kF/A2dxoCkVpHuL7eT4s7KDUnUAwS rvwUPMITKr+bWO2xyHPjUIh5wt7Uf5lbHWBvIGg1RT4sX2/7qxtMsGy8qns6BAJXHTkVWIHBohP DzQ9or X-Received: by 2002:a05:6a20:9143:b0:3c3:83e8:c209 with SMTP id adf61e73a8af0-3c3adb15e21mr18779209637.71.1784602342521; Mon, 20 Jul 2026 19:52:22 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1de301sm41167294eec.24.2026.07.20.19.52.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 19:52:22 -0700 (PDT) From: Abdurrahman Hussain Date: Mon, 20 Jul 2026 19:52:17 -0700 Subject: [PATCH RFC 3/4] of/overlay: rewrite /aliases path values to live-tree paths Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260720-nh-of-alias-overlay-v1-3-27da6848dd84@nexthop.ai> References: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> In-Reply-To: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> To: Rob Herring , Saravana Kannan Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1784602339; l=3793; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=iGWdJ4L5f5PhXUJWpbe2stIHXNaMh0PyRFQdLM6T2KQ=; b=s8Grg44XJ77C3cN110g+/qMJJmWoEBtOW0k15SkgFI5mceaPwLzOXcCeH7tyRejcKTe3IieUw pdW+6vCkfnjByjMqgJibfToBlCcRZEM9+EZCqiFCFyEO92V5pLkgHYF X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= /aliases entries added by an overlay reference labeled nodes inside the overlay via '&label' in the .dtso. dtc renders those references as string paths at compile time, but the paths encode the overlay's internal fragment layout (e.g. "/fragment@1/__overlay__/fpga@0/i2c@40000") rather than the location where the node will live after apply. Currently only /__symbols__ has its property values rewritten from overlay-internal paths to live-tree paths by dup_and_fixup_symbol_prop(). /aliases values fall through the plain __of_prop_dup() path and are copied byte-for-byte, so of_find_node_by_path() on such a value returns NULL, of_alias_get_id() reports -ENODEV =E2=80=94 and the reconfig notifier added earlier in this series sees uninterpretable paths and can't populate aliases_lookup for overlay-declared aliases. The values in /aliases follow the same textual convention as /__symbols__, so we can reuse the existing rewriter. Detect the /aliases target node and route its properties through dup_and_fixup_symbol_prop() only when the value actually looks like a fragment-internal path (non-empty, null-terminated within pp->length, "/fragment@" prefix); other alias values =E2=80=94 legacy string aliases li= ke "ttyS0" that some out-of-tree code writes verbatim =E2=80=94 pass through t= he plain __of_prop_dup() path unchanged. Discriminating up-front rather than falling back on a NULL return matters because dup_and_fixup_symbol_prop() also returns NULL on allocation failure and on malformed values. A blanket fallback would mask -ENOMEM as "not our shape" and, worse, would copy a non-null-terminated value byte-for-byte into the live tree =E2=80=94 where the alias reconfig notifier's downstream of_find_node_by_path() would treat it as a C string and read past the end. Structural validation here means a NULL from dup_and_fixup_symbol_prop() below can only be -ENOMEM and is propagated as such. Signed-off-by: Abdurrahman Hussain --- drivers/of/overlay.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c index 654a70d5cb07..69358811a7f9 100644 --- a/drivers/of/overlay.c +++ b/drivers/of/overlay.c @@ -350,6 +350,33 @@ static int add_changeset_property(struct overlay_chang= eset *ovcs, if (prop) return -EINVAL; new_prop =3D dup_and_fixup_symbol_prop(ovcs, overlay_prop); + } else if (target->np->parent && + of_node_is_root(target->np->parent) && + of_node_name_eq(target->np, "aliases") && + overlay_prop->length >=3D sizeof("/fragment@") && + overlay_prop->value && + strnlen(overlay_prop->value, overlay_prop->length) < + overlay_prop->length && + !strncmp(overlay_prop->value, "/fragment@", + strlen("/fragment@"))) { + /* + * /aliases property values that reference a labeled node + * inside this overlay are rendered by dtc as string paths + * "/fragment@N/__overlay__/..." =E2=80=94 the overlay's internal + * layout rather than where the node lives after apply. + * Reuse dup_and_fixup_symbol_prop() (which already handles + * this rewrite for /__symbols__) so of_alias_get_id() can + * resolve the value in the live tree. + * + * The property-value shape (non-empty, null-terminated + * within pp->length, prefix "/fragment@") is validated + * above so a NULL return from dup_and_fixup_symbol_prop() + * here means -ENOMEM, not "not our shape"; let the shared + * -ENOMEM check below handle it rather than falling back + * to a raw dup that would inject an unresolvable path + * into the live tree. + */ + new_prop =3D dup_and_fixup_symbol_prop(ovcs, overlay_prop); } else { new_prop =3D __of_prop_dup(overlay_prop, GFP_KERNEL); } --=20 2.54.0 From nobody Sat Jul 25 01:41:30 2026 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 107384028EE for ; Tue, 21 Jul 2026 02:52:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602351; cv=none; b=roIlQmUYLPRfknDh+zaKYj3xyfmhUPZmmPGtp/VgVIxJZyySCMV8rvcOwTO2wmHnpXlFP8lHnB0tLnbSGZgXiWOwBr7JetYpr0Ncj0uPYmds1CY/pj6nah+bE2Roc8fG48J/ldzj2UIJ5U+uerRASt238T7rJB/vUmH0//BHds8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784602351; c=relaxed/simple; bh=7I/bRIWyLMaPsbMBoV17Sw4ckfrzow+c9tKwDTtXT3w=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=sem2XIBSkUER/dTr65smXZhF/o6Wd0Gi4s+JerMqW1Jn8q7pzpcVCEBaDrEHH2yfr89rJEKEtMWWymbQ56T50pRfvOPWVNUgdgggqgizCItptTH+bYkT8ByKo1BcEjgZn+t2Wsj7+xkrIYotaKY+a0hDKSxtvjp0p5ufZ0E6gb4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai; spf=pass smtp.mailfrom=nexthop.ai; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b=FXk9fRgX; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexthop.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=nexthop.ai header.i=@nexthop.ai header.b="FXk9fRgX" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2cce6a0c9c3so96975565ad.1 for ; Mon, 20 Jul 2026 19:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1784602343; x=1785207143; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=eu/fcLH1kduLv+xVbDX9wG/kMZA8+oQXrfn0Rhdu8iA=; b=FXk9fRgXAX8dedu+3EsqbshD/CU3DRDAQ0Cyz6fM+zw6AOl3kWIBfVLBg7UwslrFii p2nKK1s5zm/k3lyvDufwvOwt5fBxwX9gmSW9k7EPfhImIZYCjYU+XDzPKnY5xCbNDLMz l0JLNUj3b0+/KdYJ/uwED90YJwiMDy9sM4Wca6h2GSAmrHmmAf5QrTD/K8xVlw5HP/12 gLVEKgoCyDg15++CjivS7bCDs4M67hHHGMhg1ngOs26TV2Zylv9ETVsXAa7vms8y9i0j 0CklKkdG7YiTnBlL8x2UpdV955W8eMGF49osPCs9hkelBImXajGJuPP5ROqst7QeQJXR lR7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784602343; x=1785207143; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=eu/fcLH1kduLv+xVbDX9wG/kMZA8+oQXrfn0Rhdu8iA=; b=at6dns8Z6F9OZADrFBMtD0brHf1165n1C9LklEJ4F9HYubptOqtHL5Mmt0olvYikgN wn9Sl7+US4VBs78sLyzCuIJZPIT9oKd5an7e+19dJVmw5SIAowoSgzJJX7229BWcde7V DFooPx/CSpyfp0VJL6kw4gY5AD/sqHrFzukgk53ruaaeNI9LxNk9QmrRt/e8EL++S09V KNPaLm0nMQ3s7ZYl+Vhb5T/OCKuMiZ+sxthNhwMo6KDLuqnwWlagt5WDlFaXUGEFmFyb zJbWEX52Ue0EjVi3yCbwgUH0otWUmXpkE6MGy+taurZtUaElAn9F5nfndKr5h1so/M25 y0Tg== X-Forwarded-Encrypted: i=1; AHgh+Rpl1+vcgyvoGG7NZb/4GirvE9W6iht/jzaqufju4RGnhl6lJgmXUcuzA588pd5nydTOJM7eP4NZrME4UMk=@vger.kernel.org X-Gm-Message-State: AOJu0YzK7MIh3o9YN2tteuJpOXPEwPFn8HJmWSGCEHXKmN4lnBh9MFtM 1foA3x3mD5DwMd5XnjgJXrQwcvyUReMQnDSSgXgWtL8UwiMO+45eKgYOsrE/ZENAbSc3TZX5Y03 EE8TIRVI= X-Gm-Gg: AR+sD114PDvV8slOckU1zbulG52puyELc7ynX3Q/sWmPQTaltWr+uL3+sTQ+8DcVYRK qCQ/twRhD1qHctoCe7inB6pyw8vv4hOu6G79f5ScUd81gW6znDpGuZI/4upNkLMZhLH6d0U2wXC 5OxVrfkT8RQBC8mX1RCiAkCrsvKVdf1JEYu0Ommo3G9g4cD8DQl/lC1TQIf9Q6X9aGPEZyFN4oS bEYUGiuKYvq2HObfF5w+NAx+0t43R3C/Xp3EMvB9OfwT9janBMG5gnQylHxaEXxL+ipRkdmmEOJ xZa1LJtbEDnMrGUourUUocsuFwBLmz98WWu4Dme361kCzUtBFlh6c0LPa/OCNHAsvO9bLXbqxEw 1Smd4xH9OTwEmL9FhTIVxGQS3VxZLjQFN6Itpwv4fKzsCWepUz1+RJ9rAjnRbEQj5Wk0v55mAkQ CEY5LShYPU0JP0qFg= X-Received: by 2002:a17:903:13c6:b0:2ce:b096:e517 with SMTP id d9443c01a7336-2cf3489548bmr179693435ad.5.1784602343335; Mon, 20 Jul 2026 19:52:23 -0700 (PDT) Received: from [127.0.0.2] ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1de301sm41167294eec.24.2026.07.20.19.52.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 19:52:22 -0700 (PDT) From: Abdurrahman Hussain Date: Mon, 20 Jul 2026 19:52:18 -0700 Subject: [PATCH RFC 4/4] of: unittest: cover /aliases updates from overlay apply/revert Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260720-nh-of-alias-overlay-v1-4-27da6848dd84@nexthop.ai> References: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> In-Reply-To: <20260720-nh-of-alias-overlay-v1-0-27da6848dd84@nexthop.ai> To: Rob Herring , Saravana Kannan Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Abdurrahman Hussain X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1784602339; l=6970; i=abdurrahman@nexthop.ai; s=20260510; h=from:subject:message-id; bh=7I/bRIWyLMaPsbMBoV17Sw4ckfrzow+c9tKwDTtXT3w=; b=JBepJEpKO1UgSdDgMBOLfMF4BXOfkw9jwwmQK8AiZVZayScTfiLy6KGsbft0QrUlQpV/SLhPN HR7yWFt0egtANLQO22TgPy8UwIGdwaWH/7sGmWBaqke3bDF2GAeGS3e X-Developer-Key: i=abdurrahman@nexthop.ai; a=ed25519; pk=omTm9cCAbO0ZhS32aKfJDKue0W3sQGpG9ub5eYHif8I= Add overlay_alias.dtso plus of_unittest_overlay_alias() to cover the "aliases inside an overlay" flow end-to-end. The overlay has two fragments: fragment@0: target-path=3D"" grafts a labeled node under target_base. fragment@1: target-path=3D"/aliases" adds `testcase-alias99 =3D &