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 v4 1/7] device property: Helper to match multiple connections
Date: Mon, 7 Mar 2022 11:13:28 -0800 [thread overview]
Message-ID: <YiZZWN1FgnWxBCuN@ripper> (raw)
In-Reply-To: <YiXZBMG7cK6Cm7wP@smile.fi.intel.com>
On Mon 07 Mar 02:05 PST 2022, Andy Shevchenko wrote:
> On Sun, Mar 06, 2022 at 07:40:34PM -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
> > Type-C connector. In this case the connector needs to belong to a graph
> > with multiple matching remote endpoints, and the Type-C controller needs
> > to be able to resolve them both.
> >
> > Add a new API that allows this kind of lookup.
>
> Thanks for the update!
>
> First of all, I have noticed that subject misses the verb, something like Add
> or Introduce.
>
Will update accordingly.
> ...
>
> > +/**
> > + * 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
>
> (Optional) array...
>
Ditto.
> > + * @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.
>
> > + * If @matches is NULL @matches_len is ignored and the total number of resolved
> > + * matches is returned.
>
> I would require matches_len to be 0, see below.
>
> > + * Return: Number of matches resolved, or negative errno.
> > + */
> > +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_graph;
> > + unsigned int count_ref;
> > +
> > + if (!fwnode || !match)
> > + return -EINVAL;
> > +
> > + count_graph = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> > + matches, matches_len);
>
> > + if (matches) {
> > + matches += count_graph;
> > + matches_len -= count_graph;
> > + }
>
> So, the valid case is matches != NULL and matches_len == 0. For example, when
> we have run something previously on the buffer and it becomes full.
>
> In this case we have carefully handle this case.
>
> if (matches) {
> matches += count_graph;
> if (matches_len)
> matches_len -= count_graph;
When matches is non-NULL, both the sub-functions are limited by
matches_len and as such count_graph <= matches_len.
As such matches_len >= 0.
In the event that the originally passed matches_len was 0, then
count_graph will be 0 and matches_len will remain 0.
I therefor don't see that this additional check changes things.
> }
>
> Seems it can be also
>
> if (matches)
> matches += count_graph;
>
> if (matches_len)
> matches_len -= count_graph;
We covered the case of matches && (matches_len || !matches_len) above.
For the case of !matches && matches_len, this added conditional would
cause matches_len to be extra ignored by keeping it at 0, but per
kernel-doc and implementation we ignore all other values already.
Note that this is in contrast from vsnprintf() where the code will
continue to produce results, only store the first "matches_len"
entires and return the final count.
Unfortunately we can't follow such semantics here, instead it is clearly
documented in the kernel-doc that @matches_len is ignored when @matches
is NULL.
So unless I'm missing something I don't see what you gain over keeping
the check on only matches.
>
> That said, do we have a test cases for this?
>
I looked briefly at adding some kunit tests for this, but was discourage
by the prospect of building up the graphs to run the tests against.
Regards,
Bjorn
> > + count_ref = fwnode_devcon_matches(fwnode, con_id, data, match,
> > + matches, matches_len);
> > +
> > + return count_graph + count_ref;
> > +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
prev parent reply other threads:[~2022-03-07 19:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 3:40 [PATCH v4 1/7] device property: Helper to match multiple connections Bjorn Andersson
2022-03-07 3:40 ` [PATCH v4 2/7] device property: Use multi-connection matchers for single case Bjorn Andersson
2022-03-07 3:40 ` [PATCH v4 3/7] usb: typec: mux: Check dev_set_name() return value Bjorn Andersson
2022-03-07 10:08 ` Andy Shevchenko
2022-03-07 14:33 ` Bjorn Andersson
2022-03-07 14:52 ` Heikki Krogerus
2022-03-07 3:40 ` [PATCH v4 4/7] usb: typec: mux: Introduce indirection Bjorn Andersson
2022-03-07 3:40 ` [PATCH v4 5/7] usb: typec: mux: Allow multiple mux_devs per mux Bjorn Andersson
2022-03-07 3:40 ` [PATCH v4 6/7] dt-bindings: usb: Add binding for fcs,fsa4480 Bjorn Andersson
2022-03-07 3:40 ` [PATCH v4 7/7] usb: typec: mux: Add On Semi fsa4480 driver Bjorn Andersson
2022-03-07 10:16 ` Andy Shevchenko
2022-03-07 14:48 ` Bjorn Andersson
2022-03-07 16:13 ` Andy Shevchenko
2022-03-07 21:04 ` Bjorn Andersson
2022-03-07 22:13 ` Andy Shevchenko
2022-03-08 0:01 ` Bjorn Andersson
2022-03-07 10:05 ` [PATCH v4 1/7] device property: Helper to match multiple connections Andy Shevchenko
2022-03-07 19:13 ` Bjorn Andersson [this message]
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=YiZZWN1FgnWxBCuN@ripper \
--to=bjorn.andersson@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--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.