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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox