All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Subject: Re: [PATCH v2 1/6] device property: Helper to match multiple connections
Date: Wed, 9 Feb 2022 14:30:32 +0200	[thread overview]
Message-ID: <YgOz6K55Oi2Si4pU@smile.fi.intel.com> (raw)
In-Reply-To: <20220208031944.3444-2-bjorn.andersson@linaro.org>

On Mon, Feb 07, 2022 at 07:19:39PM -0800, Bjorn Andersson wrote:
> In some cases multiple connections with the same connection id
> needs to be resolved from a fwnode graph.
> 
> One such example is when separate hardware is used for performing muxing
> and/or orientation switching of the SuperSpeed and SBU lines in a USB-C

USB Type-C ?

> connector. In this case the connector needs to belong to a graph with
> multiple matching remote endpoints, and the TypeC controller needs to be

Type-C ?

> able to resolve them both.
> 
> Add a new API that allows this kind of lookup.
> 
> Given that the match() callback returns an opaque reference to something
> provided by the client it's not possible for the implementation to
> release the returned object and as such it's not possible to handle
> errors, which in turn means that it's not possible to query the number
> of elements or dynamically grow the results array. It's however expected
> that the number of matches will be reasonably low and that the worst
> case is known by the caller before hand.

...

> +	fwnode_graph_for_each_endpoint(fwnode, ep) {
> +		if (count >= matches_len) {
> +			fwnode_handle_put(ep);
> +			return count;
> +		}
> +
> +		node = fwnode_graph_get_remote_port_parent(ep);
> +		if (!fwnode_device_is_available(node)) {
> +			fwnode_handle_put(node);
> +			continue;
> +		}
> +
> +		ret = match(node, con_id, data);
> +		fwnode_handle_put(node);

> +

Redundant blank line (it seems the current style w/o this).
Ditto for the below function.

> +		if (ret)
> +			matches[count++] = ret;
> +	}

...

> +/**
> + * fwnode_connection_find_matches - Find connections from a device node
> + * @fwnode: Device node with the connection
> + * @con_id: Identifier for the connection
> + * @data: Data for the match function
> + * @match: Function to check and convert the connection description
> + * @matches: Array of pointers to fill with matches
> + * @matches_len: Length of @matches
> + *
> + * Find up to @matches_len connections with unique identifier @con_id between
> + * @fwnode and other device nodes. @match will be used to convert the
> + * connection description to data the caller is expecting to be returned
> + * through the @matches array.
> + *
> + * Return: Number of matches resolved, of negative errno.

s/of/or/ ?

> + */
> +int fwnode_connection_find_matches(struct fwnode_handle *fwnode,
> +				   const char *con_id, void *data,
> +				   devcon_match_fn_t match,
> +				   void **matches, unsigned int matches_len)
> +{
> +	unsigned int count;
> +
> +	if (!fwnode || !match || !matches)

!matches case may be still useful to get the count and allocate memory by
caller. Please, consider this case.

> +		return -EINVAL;
> +
> +	count = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> +					    matches, matches_len);
> +
> +	return count + fwnode_devcon_matches(fwnode, con_id, data, match,
> +					     matches + count,
> +					     matches_len - count);

I haven't found any explanation what the difference between two counts. Also
can you define two count variables with distinct names and do something like

	count_A = ...

	matches += count;
	matches_len -= count;

	count_B = ...

	return count_A + count_B;

?

> +}

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-02-09 12:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08  3:19 [PATCH v2 0/6] typec: mux: Introduce support for multiple TypeC muxes Bjorn Andersson
2022-02-08  3:19 ` [PATCH v2 1/6] device property: Helper to match multiple connections Bjorn Andersson
2022-02-09 12:30   ` Andy Shevchenko [this message]
2022-02-18 19:00     ` Bjorn Andersson
2022-02-20 11:16       ` Andy Shevchenko
2022-02-21  4:55         ` Bjorn Andersson
2022-02-21 17:19           ` Andy Shevchenko
2022-02-21 19:08             ` Bjorn Andersson
2022-02-08  3:19 ` [PATCH v2 2/6] device property: Use multi-connection matchers for single case Bjorn Andersson
2022-02-08  3:19 ` [PATCH v2 3/6] typec: mux: Introduce indirection Bjorn Andersson
2022-02-18 10:39   ` Heikki Krogerus
2022-02-08  3:19 ` [PATCH v2 4/6] typec: mux: Allow multiple mux_devs per mux Bjorn Andersson
2022-02-18 10:40   ` Heikki Krogerus
2022-02-08  3:19 ` [PATCH v2 5/6] dt-bindings: usb: Add binding for fcs,fsa4480 Bjorn Andersson
2022-02-11 16:35   ` Rob Herring
2022-02-08  3:19 ` [PATCH v2 6/6] usb: typec: mux: Add On Semi fsa4480 driver Bjorn Andersson
2022-02-08 13:24   ` Andy Shevchenko
2022-02-10 10:00 ` [PATCH v2 0/6] typec: mux: Introduce support for multiple TypeC muxes Hans de Goede

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=YgOz6K55Oi2Si4pU@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=djrscally@gmail.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=hdegoede@redhat.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.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.