From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Ahmad Byagowi <ahmadexp@gmail.com>
Cc: Andi Shyti <andi.shyti@kernel.org>,
Peter Rosin <peda@lysator.liu.se>,
Andy Shevchenko <andy@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 2/2] i2c: mux: Propagate firmware nodes to channel adapters
Date: Tue, 8 Sep 2026 13:43:01 +0300 [thread overview]
Message-ID: <ap_mtZa1bGidHXfq@ashevche-desk.local> (raw)
In-Reply-To: <00b33b4b352848ff87dd9089190b35d8732676f3.1788623619.git.ahmadexp@gmail.com>
On Mon, Sep 07, 2026 at 11:26:23PM -0700, Ahmad Byagowi wrote:
> Device Tree channel nodes are associated with the adapters created by
> i2c-mux, but equivalent firmware-node descriptions are not.
>
> Use generic firmware-node operations for the existing channel lookup
> and associate the returned node with the adapter. Do not restrict the
> lookup by firmware-node type, so Device Tree, software nodes, and ACPI
> descriptions all follow the same property traversal. The existing
> acpi_preset_companion() call remains in place for the standard ACPI
> channel association.
>
> Keep a separate reference to the node returned by the generic lookup
> because acpi_preset_companion() may replace the device's primary
> firmware node. Release the saved reference after adapter deletion.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
...
> - struct device_node *dev_node;
> - struct device_node *mux_node;
> - struct device_node *child;
> + struct fwnode_handle *dev_node;
> + struct fwnode_handle *mux_node;
> + struct fwnode_handle *child;
When the local variable changes the type (usually this is related to
the pointers) the best practice is to rename. In such a case it will
avoid the cases when some API accepts void * and the change would not
have been noticed until run-time crash or subtle issues.
I hope here it's just a mechanical stuff and we don't have side effects
as per above.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-09-08 10:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 6:26 [PATCH v10 0/2] i2c: mux: Propagate firmware nodes to channel adapters Ahmad Byagowi
2026-09-08 6:26 ` [PATCH v10 1/2] i2c: mux: Factor out channel node lookup Ahmad Byagowi
2026-09-08 10:39 ` Andy Shevchenko
2026-09-10 13:44 ` Peter Rosin
2026-09-08 6:26 ` [PATCH v10 2/2] i2c: mux: Propagate firmware nodes to channel adapters Ahmad Byagowi
2026-09-08 10:43 ` Andy Shevchenko [this message]
2026-09-08 13:12 ` Ahmad Byagowi
2026-09-10 13:44 ` Peter Rosin
2026-09-10 13:47 ` [PATCH v10 0/2] " Peter Rosin
2026-09-16 22:07 ` 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=ap_mtZa1bGidHXfq@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.