devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Herve Codina <herve.codina@bootlin.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Herve Codina <herve.codina@bootlin.com>
Subject: [RFC PATCH 1/3] i2c: core: Follow i2c-parent when retrieving an adapter from node
Date: Wed,  5 Feb 2025 18:39:14 +0100	[thread overview]
Message-ID: <20250205173918.600037-2-herve.codina@bootlin.com> (raw)
In-Reply-To: <20250205173918.600037-1-herve.codina@bootlin.com>

i2c bus extensions were introduced to decouple i2c busses when they are
wired to connectors. Combined with devicetree overlays, they introduce
an additional level of indirection, which is needed to decouple the
overlay (describing the hardware available on addon baord) and the base
tree (describing resources provided to the addon board).

For instance, the following devicetree fragment, available once
overlays are applied, is legit:

    i2c1: i2c@abcd0000 {
        compatible = "xyz,i2c-ctrl";
        i2c-bus-extension@0 {
            reg = <0>;
            i2c-bus = <&i2c-ctrl>;
        };
        ...
    };

    connector {
        i2c-ctrl {
            i2c-parent = <&i2c1>;
            #address-cells = <1>;
            #size-cells = <0>;

            i2c-bus-extension@0 {
                reg = <0>;
                i2c-bus = <&i2c-other-connector>;
            };

            device@10 {
                compatible = "xyz,foo";
                reg = <0x10>;
            };
        };

        devices {
            other-connector {
                i2c-at-other-connector {
                    i2c-parent = <&i2c-ctrl>;
                    #address-cells = <1>;
                    #size-cells = <0>;

                    device@20 {
                       compatible = "xyz,bar";
                       reg = <0x20>;
                    };
                };
            };
        };
    };

Current implementation of i2c_find_adapter_by_fwnode() supposes that the
fwnode parameter correspond to the adapter.

This assumption is no more valid with i2c bus extensions. Indeed, the
fwnode parameter can reference an i2c bus extension node and not the
related adapter.

In the example, i2c-ctrl and i2c-at-other-connector nodes are chained
bus extensions and those node can be passed to
i2c_find_adapter_by_fwnode() in order to get the related adapter (i.e
the adapter handling the bus and its extensions: i2c@abcd0000).

Extend i2c_find_adapter_by_fwnode() to perform the walking from the
given fwnode through i2c-parent references up to the adapter.

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
 drivers/i2c/i2c-core-base.c | 43 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 5546184df05f..cb7adc5c1285 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1827,14 +1827,55 @@ static int i2c_dev_or_parent_fwnode_match(struct device *dev, const void *data)
  */
 struct i2c_adapter *i2c_find_adapter_by_fwnode(struct fwnode_handle *fwnode)
 {
+	struct fwnode_reference_args args;
+	struct fwnode_handle *adap_fwnode;
 	struct i2c_adapter *adapter;
 	struct device *dev;
+	int err;
 
 	if (!fwnode)
 		return NULL;
 
-	dev = bus_find_device(&i2c_bus_type, NULL, fwnode,
+	adap_fwnode = fwnode_handle_get(fwnode);
+
+	/* Walk extension busses (through i2c-parent) up to the adapter node */
+	while (fwnode_property_present(adap_fwnode, "i2c-parent")) {
+		/*
+		 * A specific case exists for the i2c demux pinctrl. The i2c bus
+		 * node related this component (the i2c demux pinctrl node
+		 * itself) has an i2c-parent property set. This property is used
+		 * by the i2c demux pinctrl component for the demuxing purpose
+		 * and is not related to the extension bus feature.
+		 *
+		 * In this current i2c-parent walking, the i2c demux pinctrl
+		 * node has to be considered as an adapter node and so, if
+		 * the adap_fwnode node is an i2c demux pinctrl node, simply
+		 * stop the i2c-parent walking.
+		 */
+		if (fwnode_property_match_string(adap_fwnode, "compatible",
+						 "i2c-demux-pinctrl") >= 0)
+			break;
+
+		/*
+		 * i2c-parent property available in a i2c bus node means that
+		 * this node is an extension bus node. In that case,
+		 * continue i2c-parent walking up to the adapter node.
+		 */
+		err = fwnode_property_get_reference_args(adap_fwnode, "i2c-parent",
+							 NULL, 0, 0, &args);
+		if (err)
+			break;
+
+		pr_debug("Find adapter for %pfw, use parent: %pfw\n", fwnode,
+			 args.fwnode);
+
+		fwnode_handle_put(adap_fwnode);
+		adap_fwnode = args.fwnode;
+	}
+
+	dev = bus_find_device(&i2c_bus_type, NULL, adap_fwnode,
 			      i2c_dev_or_parent_fwnode_match);
+	fwnode_handle_put(adap_fwnode);
 	if (!dev)
 		return NULL;
 
-- 
2.47.1


  reply	other threads:[~2025-02-05 17:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 17:39 [RFC PATCH 0/3] i2c: Introduce i2c bus extensions Herve Codina
2025-02-05 17:39 ` Herve Codina [this message]
2025-04-03  9:03   ` [RFC PATCH 1/3] i2c: core: Follow i2c-parent when retrieving an adapter from node Wolfram Sang
2025-04-03 10:50     ` Herve Codina
2025-04-03 11:20       ` Wolfram Sang
2025-04-03 12:21         ` Herve Codina
2025-02-05 17:39 ` [RFC PATCH 2/3] i2c: i2c-core-of: Move children registration in a dedicated function Herve Codina
2025-04-03  9:07   ` Wolfram Sang
2025-04-03 10:51     ` Herve Codina
2025-02-05 17:39 ` [RFC PATCH 3/3] i2c: i2c-core-of: Handle i2c bus extensions Herve Codina
2025-02-12  5:54   ` Krzysztof Kozlowski
2025-02-12  9:45     ` Herve Codina
2025-04-03  9:09   ` Wolfram Sang
2025-02-19 13:38 ` [RFC PATCH 0/3] i2c: Introduce " Herve Codina
2025-03-20 12:49 ` Wolfram Sang
2025-03-20 16:31   ` Luca Ceresoli
2025-03-20 21:37     ` Wolfram Sang
2025-04-03  9:15 ` Wolfram Sang
2025-06-12  7:52 ` Ayush Singh
2025-06-13  7:30   ` Herve Codina
2025-07-03 11:26     ` Ayush Singh
2025-07-03 15:19       ` Herve Codina

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=20250205173918.600037-2-herve.codina@bootlin.com \
    --to=herve.codina@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=robh@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wsa+renesas@sang-engineering.com \
    /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;
as well as URLs for NNTP newsgroup(s).