From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Ahmad Byagowi <ahmadexp@gmail.com>
Cc: Peter Rosin <peda@lysator.liu.se>,
Andy Shevchenko <andy@kernel.org>,
Andi Shyti <andi.shyti@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/3] i2c: mux: Propagate software nodes to channel adapters
Date: Mon, 31 Aug 2026 10:25:44 +0300 [thread overview]
Message-ID: <apUseMqUa6_mL2If@ashevche-desk.local> (raw)
In-Reply-To: <CAOQiBWOZd+NVRqzRzJx9HP+B21JJXBUTy_OxAqDw8X7tvWeY+w@mail.gmail.com>
On Sat, Aug 29, 2026 at 10:04:13PM -0700, Ahmad Byagowi wrote:
Please, stop top-posting!
> Peter, thanks for clarifying.
> The check is intentional as 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.
> 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.
> That being said, I will clarify that in the commit message for the next
> revision.
Also use proper check then if (!is_acpi_node(...)) or more granular one
(ACPI device or data node in case you we are talking about certain type
of it).
> On Sat, Aug 29, 2026 at 9:55 PM Peter Rosin <peda@lysator.liu.se> wrote:
>
> > Den Thu, Aug 27, 2026 at 09:11:31AM +0300, skrev Andy Shevchenko:
> > > On Wed, Aug 26, 2026 at 08:29:47AM -0700, Ahmad Byagowi wrote:
...
> > > Wouldn't it be possible to use some kind of DT overlay to have that?
> >
> > For me, the above is a bit unrelated to this patch series, which is
> > about converting i2c-mux from of-only properties to device properties.
> > That seems like a change that stands on its own.
> >
> > I probably wasn't clear enough with my original question, but what I
> > wondered about was what regression risk that conversion might have
> > for the ACPI case. Specifically, there might be ACPI properties that
> > match what the code is now looking for. It seems unlikely that such
> > properties are actually deployed, but I know next to nothing about
> > ACPI...
> >
> > TL;DR
> >
> > My original question should have been: Is it safe to simply remove
> > these lines from the patch:
> > > + if (!is_of_node(dev_node) && !is_software_node(dev_node))
> > > + return NULL;
> > and let the code trawl all kinds of device properties?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-08-31 7:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 16:34 [PATCH v7 0/3] i2c: mux: Propagate software nodes to channel adapters Ahmad Byagowi
2026-08-23 16:34 ` [PATCH v7 1/3] i2c: mux: Fix channel node leak on adapter add failure Ahmad Byagowi
2026-08-25 5:49 ` Peter Rosin
2026-08-23 16:34 ` [PATCH v7 2/3] i2c: mux: Factor out channel node lookup Ahmad Byagowi
2026-08-25 5:50 ` Peter Rosin
2026-08-23 16:34 ` [PATCH v7 3/3] i2c: mux: Propagate software nodes to channel adapters Ahmad Byagowi
2026-08-25 5:50 ` Peter Rosin
[not found] ` <CAOQiBWNVvHpO7X8yWyZEa3-nV76YJfRbkzo+_4U-upEj4VNfow@mail.gmail.com>
2026-08-26 16:39 ` Ahmad Byagowi
2026-08-27 6:11 ` Andy Shevchenko
2026-08-30 4:55 ` Peter Rosin
2026-08-30 5:10 ` Ahmad Byagowi
2026-08-31 7:13 ` Peter Rosin
2026-08-31 7:28 ` Andy Shevchenko
2026-08-31 7:22 ` Andy Shevchenko
[not found] ` <CAOQiBWOZd+NVRqzRzJx9HP+B21JJXBUTy_OxAqDw8X7tvWeY+w@mail.gmail.com>
2026-08-31 7:25 ` Andy Shevchenko [this message]
2026-08-26 13:45 ` [PATCH v7 0/3] " Andi Shyti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apUseMqUa6_mL2If@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=ahmadexp@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=andy@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@lysator.liu.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.