Re: [PATCH v7 3/3] i2c: mux: Propagate software nodes to channel adapters

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Mon, Aug 31, 2026 at 09:13:34AM +0200, Peter Rosin wrote:
> Den Sat, Aug 29, 2026 at 10:10:40PM -0700, skrev Ahmad Byagowi:
> > Peter, thanks for clarifying.
> > 
> > The check is intentional. Without it, the generic traversal would also
> > inspect ACPI firmware nodes and could match _DSD child nodes carrying
> > a "reg" property, while the existing ACPI path below uses
> > acpi_preset_companion() to associate the adapter by channel address.
> 
> Yes, I got that. The question is if the precaution is really needed.
> Are "reg" properties common in ACPI nodes?

Nope, and we have documented how ACPI DSDT is supposed to be constructed for
the I²C muxes, but as I answered there, it relies on a human (factor).

> > I have not established that changing the ACPI lookup behavior is safe,
> > and that change is not needed for software-node support. With the
> > check retained, OF and software nodes use the generic lookup, while
> > ACPI continues to use the existing acpi_preset_companion() path
> > exclusively.
> 
> Yes, I figured as much, which is why I directed the question at Andy.
> 
> > That said, I will clarify this in the commit message for the next revision.
> 
> I'd rather tweak the check to exclude ACPI (instead of including OF and
> SW) with a code comment about why ACPI is excluded. That is, if it can
> be determined that ACPI actually needs to be excluded. If it is hard to
> get an answer to that question, I'm inclined to just attempt to not
> exclude ACPI, and then be prepared to exclude ACPI in a follow-up if
> there is any fallout.

Agree (and also answered in the similar way earlier).

-- 
With Best Regards,
Andy Shevchenko