Re: [PATCH v8 0/6] of: teach overlay code to keep /aliases in sync

["Abdurrahman Hussain" <abdurrahman@nexthop.ai>]

On Thu, Nov 05, 2026 at 06:40:30AM -0600, Rob Herring wrote:
> I'd rather have my added device working than refusing to probe because
> some arbitrary device index couldn't be used. There may be some user
> that has a working system today and then this change would break them.
> We can't really have that. I view aliases as a request, not a
> requirement. It's perfectly valid for an OS to just ignore them
> completely.
>
> I have no issue if we make the failure to use an alias louder, but I
> guess that's not your main issue.

OK. I'll drop that from overlay-notes.rst.

Watchdog and rtc already treat an alias as a request: they try the
aliased id and take a dynamic one if it is in use. The subsystems that
fail are the ones that keep their dynamic range clear of boot-time aliases,
which they cannot do for an overlay applied later: i2c, i3c, spi and
mmc. On x86/ACPI and other systems booting without a base DT there are
no boot-time aliases at all, so that range is empty and dynamic
numbering starts at 0, right where overlay aliases would land.

Would you like v9 to give those four the same fallback, with a warning,
so the behaviour is consistent across subsystems? For i2c, the alias
lookup would move into i2c_allocate_adapter_id(), so i2c_add_adapter()
just sets nr = -1:

	if (adap->nr == -1)
		alias = of_alias_get_id(adap->dev.of_node, "i2c");
	...
	mutex_lock(&core_lock);
	if (alias >= 0) {
		id = idr_alloc(&i2c_adapter_idr, NULL, alias, alias + 1,
			       GFP_KERNEL);
		if (id != -ENOSPC)
			goto unlock;
		pr_warn("adapter '%s': alias i2c%d already in use, using a dynamic bus number\n",
			adap->name, alias);
	}
	id = idr_alloc(&i2c_adapter_idr, NULL, start, end, GFP_KERNEL);
unlock:
	mutex_unlock(&core_lock);

i3c, spi and mmc would get the same few lines in their id allocation.
mtd and serial don't keep a range clear for aliases, so boot-time
aliases can already collide there today; I'd leave them for a
follow-up.

That would extend the series beyond drivers/of into four subsystems,
with acks needed from their maintainers, so I wanted to check you're
OK with that scope before going ahead.

Your two earlier suggestions, keeping alias and dynamic ranges apart
or only honoring overlay aliases whose names are absent from the base
DT, run into the same empty range: the first would reject every
overlay alias, the second would accept every one.

Thanks,
Abdurrahman