Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 18 Feb 2022 11:00:45 -0800
From:   Bjorn Andersson <bjorn.andersson@linaro.org>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
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
Message-ID: <Yg/s3eKB2wLEQTgY@ripper>
References: <20220208031944.3444-1-bjorn.andersson@linaro.org>
 <20220208031944.3444-2-bjorn.andersson@linaro.org>
 <YgOz6K55Oi2Si4pU@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YgOz6K55Oi2Si4pU@smile.fi.intel.com>
Precedence: bulk

On Wed 09 Feb 04:30 PST 2022, Andy Shevchenko wrote:

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

As discussed in previous version, and described in the commit message,
the returned value of "match" is a opaque pointer to something which
has to be passed back to the caller in order to be cleaned up.

E.g. the typec mux code returns a pointer to a typec_mux/switch object
with a refcounted struct device within, or an ERR_PTR().

So unfortunately we can must gather the results into matches and pass it
back to the caller to take consume or clean up.


Thanks for your review, I'll update the patches according to the
other feedback.

Regards,
Bjorn

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