From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f13.google.com (mail-pj2-f13.google.com [74.125.227.141]) (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 D2DEA3C3442 for ; Fri, 18 Sep 2026 02:21:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.141 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789698095; cv=none; b=QYzZk0MdVsLUnvRXy/taNlSoKwcXdsUGKhPWi8+SicU1VdfldRqQmz7fsRwn9r1JkNdTvzdiGovEqrAAdkH+GX/9h6Dvmvpq72rZz6koWsMerdWcxKUs6b1FrGKqTUiMFuUb5qDcLIf/xUxBaEPy64256YV9d6W+0Vvkd/tQEqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789698095; c=relaxed/simple; bh=tUw2b7crU+HHHqcx/66Gimzh2XvrG+qMeLaV1m8ApW0=; h=Content-Type:Date:Message-Id:To:Cc:Subject:From:Mime-Version: References:In-Reply-To; b=izSfGMhm1thMZ7bCM78TLU67vsc6BWaeKLLVcoCRXLIJTKfntwj9OyU1oFvn6Hqu0ASx3GQMJ8SyRNIFvQz1l1sVoF8f8RWM2hCD2Els6fJz1QGHuEYQvU17u5GyOiGs+g8tAZmXenzyQXnFckPaq2ljr2dbfJJzjf5HsIoHzWg= 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=gKcImSqE; arc=none smtp.client-ip=74.125.227.141 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="gKcImSqE" Received: by mail-pj2-f13.google.com with SMTP id d9443c01a7336-2d747eb79f6so1460415ad.0 for ; Thu, 17 Sep 2026 19:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexthop.ai; s=google; t=1789698085; x=1790302885; darn=vger.kernel.org; h=in-reply-to:references:content-transfer-encoding:mime-version:from :subject:cc:to:message-id:date:content-type:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EZ/9bEBYN1Z12jKLfTJjtmiNcTyLLJmUMtlMsC9kMPw=; b=gKcImSqEmdoYC5Fgr/5ueGjyHsJSFbcfwDgZAU0AhtDvYPKUWLdx5D4PuStEAzmHk4 xiLrAWxOln6K9XPTweM19KhHDg8BrgpU33wc4iAbb1Zcm7I2/Lw4Jl3PaabJV01D8+jF UsbwTgjwaJD5a1vmBb5FoscUMrkqufba0SS8l9I8+smM74HY1rhOE1JkC/cehphDNepW r5DoGggL9dGDKrdsL661lyhh/xagT1S5MieH2yUusy9UJBJ7RUuSZQUQWm/32+NHp3ZT 7V51Iokq6lZYr4Mt9D43Od8LGt9qDFtwlL1vtPAnZOM78pHByVDI8SKEpO+0s9Kj9bMf Trrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789698085; x=1790302885; h=in-reply-to:references:content-transfer-encoding:mime-version:from :subject:cc:to:message-id:date:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EZ/9bEBYN1Z12jKLfTJjtmiNcTyLLJmUMtlMsC9kMPw=; b=bKA3dvG9UuDlwyQTJ0Z6cguWiSJDxRefj6/kRdsRvZeU+zIM4I7eoSOEtBAvkdZl04 EpIMJyfma5Tl5ilCEl7cFD9hPf48ArIKVm+XJETot35R0RXqhXqKRTl8jWjMANQkzMKU F+Vkzy3HWcwf7QY2KaqDYsIgDuL+Dk+Rf7FS/R1gEfP+KXZBRF9LNd73PfffA6kq/oEY Y/+/8bdx3t9k9uzElrMV1wL9KUOvNa8mz039BkgoT4ybucYKKBvhIju3OvhIaMrqbEoP VQ2JYEmEY7k7dvOHHLIX2Vbp2Qdi4NuGDTI1d5/Zdn5iggSkT1VD5JhhDsV1prAT3kBT f2xg== X-Forwarded-Encrypted: i=1; AKwUvBzvM5DUx4kPqYwiYcP2LXS8NHeXEPvmOFDbTWslZvHoU+vthG2sy9PO1Bmci4m0YC0AR6r+lpAUgglP3Eg=@vger.kernel.org X-Gm-Message-State: AFuF++kpNW+UdwQXlUvvcyZjcwP7dbCTtb5ZIfe2IoBAzYX8/ZArcydu aez6DrAk0F6q9Zbe6igQ0B3EXtyD3fZqAUAtlYTRkBHeliwOxgupRx62MrauJhU4neCQmYC3OPf bvRHqh9c= X-Gm-Gg: AYBFou3MDBxQEJ3ZMvzsd4LcNUhv8HyKIk9n9S+hQ8h4oEuUOXQTgJSNIW1TjQw2uqe t/Yc4a7RXWoqgqV9pIfsXOF8td1Oy1eRiIYbjW2YuciLDNol5+gXOkrL4mPfAcrYPi8whuQk+nf 055mpLkX4yw8MBsFB/OLpDA9GdebXzzzLz1GM+vWwYUEiHpuYZZxH2DPriqC0PjPB2fIYB4mNvY juRcarBIKLc/wTfiQpm3s2M9YEaBGbSg1gzj6w4NWgCofqdwaeOtm9vbtEg+QdaKnAUePfkpLh9 QR0Fj8jaDltkNyM4kDC+inTXYgU75l0ORH8a9AKQtrpYOMsSHrV2N4Krncrt2TqylX2pob/5jxL DpAubPRAwOmcok3EjAfLNvUsO3YUrJjYXwo6ns0OOD0aAHRC1drJg9SKzdEeU4DmlVLQ59XrzPA QZ9y9MasLn4acgo64x0K09o/o2Y8BoKeoO1pgNWPsx6bI+/bgEDOmNtVOgWXJjkRUYZESZwK4f6 uVXIQH5MQ== X-Received: by 2002:a17:90a:d005:b0:39d:ba21:fd90 with SMTP id 98e67ed59e1d1-39e54f2bf77mr4084275a91.16.1789698085330; Thu, 17 Sep 2026 19:21:25 -0700 (PDT) Received: from localhost ([50.145.100.174]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-33c2876ad4dsm219835eec.21.2026.09.17.19.21.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2026 19:21:24 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 Date: Thu, 17 Sep 2026 19:21:23 -0700 Message-Id: To: "Rob Herring" , "Abdurrahman Hussain" Cc: "Saravana Kannan" , "Frank Rowand" , "David S. Miller" , "Shawn Guo" , "Grant Likely" , "Grant Likely" , "Pantelis Antoniou" , "David Daney" , , , , "Geert Uytterhoeven" , "Geert Uytterhoeven" , "Sashiko AI" Subject: Re: [PATCH v7 00/10] of: teach overlay code to keep /aliases in sync From: "Abdurrahman Hussain" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: aerc 0.22.0 References: <20260831-nh-of-alias-overlay-v7-0-02754604805a@nexthop.ai> <20260917203938.GA3480871-robh@kernel.org> In-Reply-To: <20260917203938.GA3480871-robh@kernel.org> On Thu Sep 17, 2026 at 1:39 PM PDT, Rob Herring wrote: > There was another posting in 2024 of Geert's patches and AFAICT my > comment there[1] still applies. To repeat, what happens if the alias > number already got used because the subsystems can pick any of the > numbers without an alias. The only way I see to solve that is make > possible alias numbers and dynamic numbers non-overlapping or only allow > alias names that are not present in the base DT to be used/honored in > overlays. Thanks, I missed that thread. I went through what the users of of_alias_get_id() actually do when the index is taken, to see how bad the collision is in practice: i2c: i2c_add_adapter() -> i2c_allocate_adapter_id() does idr_alloc(nr, nr + 1). Taken index -> -EBUSY plus pr_err("adapter '%s': failed to allocate id"), adapter is not registered. spi: spi_register_controller() -> spi_controller_id_alloc(bus_num, bus_num + 1). Taken index -> WARN() and -EBUSY, controller is not registered. serial: serial_port.c sets port->line from the alias; serial_core_add_one_port() returns -EINVAL if that line already has a uart_port. So a collision is a loud probe failure, never two devices on one number or a device silently landing somewhere else. What changes with this series is the failure mode for an overlay that asks for an index which a dynamic allocation already took: today the alias is ignored and the device quietly gets a dynamic number (which is exactly the bug the series is fixing, since the pinned number was the point of the alias); with the series the probe fails and says why. I think that is the right contract: an alias is a request for a specific number, and refusing it is more useful than pretending it was honored. It matches what already happens in the base DT if two aliases name the same index, or if a driver calls i2c_add_numbered_adapter() with a taken number. On the two alternatives you list: Non-overlapping ranges: the subsystems already try. i2c computes __i2c_first_dynamic_bus_num from of_alias_get_highest_id("i2c") at init and spi re-reads the highest id at each dynamic registration, so dynamic numbers start above every boot-time alias. What they cannot do is reserve numbers for an overlay that has not been loaded yet. The OF core could refuse an overlay alias whose index is at or below the subsystem's dynamic floor, but it does not know that floor; it would need a per-stem hook from every subsystem, and I do not think the mechanism is worth it for what it buys. In practice the overlay author picks an index well above anything the base system can allocate dynamically, and if they guess wrong they get -EBUSY in dmesg pointing at the adapter, not a misnumbered bus. Only honoring names absent from the base DT: that addresses a different case, an overlay redefining an existing alias to point at another node. The notifier already handles that one: an OF_RECONFIG_UPDATE_PROPERTY on /aliases destroys the old entry before creating the new one, so the old node loses the id and the new node gains it. Whether the overlay should be allowed to do that at all is a policy question I am happy to go either way on; rejecting it is a two-line check in the notifier. But it does not help with the dynamic id case, because the colliding number there was never an alias in the first place. If you would rather see the failure mode documented than argued, I can add a paragraph to Documentation/devicetree/overlay-notes.rst in v8 stating that an overlay alias index which is already in use causes the device registration to fail. > Fixes should come first in a series. Then I can apply them if ready even > if the feature patches are not ready. Understood, and thanks for taking 4-7. v8 will be based on dt/linus with the remaining fixes (find_target absolute lookup, ERR_PTR from dup_and_fixup_symbol_prop) first, then the /aliases patches. Abdurrahman