All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Herve Codina <herve.codina@bootlin.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	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>
Subject: Re: [RFC PATCH 1/3] i2c: core: Follow i2c-parent when retrieving an adapter from node
Date: Thu, 3 Apr 2025 11:03:27 +0200	[thread overview]
Message-ID: <Z-5O3-FSsHbn27lW@shikoro> (raw)
In-Reply-To: <20250205173918.600037-2-herve.codina@bootlin.com>

[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]


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

Even with the review of the schema going on, here are some comments
already.

> 
> 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;

I understand the unlikeliness of another demux driver showing up, yet
relying on compatible-values here is too easy to get stale. What about
checking if the i2c-parent property has more than one entry? That should
be only true for demuxers.

> +
> +		/*
> +		 * 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);

Is this useful when creating the overlays? I tend to ask you to remove
it one RFC phase is over. If it is useful, it should be at least
dev_dbg?

> +
> +		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
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2025-04-03  9:03 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 ` [RFC PATCH 1/3] i2c: core: Follow i2c-parent when retrieving an adapter from node Herve Codina
2025-04-03  9:03   ` Wolfram Sang [this message]
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=Z-5O3-FSsHbn27lW@shikoro \
    --to=wsa+renesas@sang-engineering.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=herve.codina@bootlin.com \
    --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 \
    /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.