Re: [PATCH v3 1/6] device property: Helper to match multiple connections

Bjorn Andersson
2022-03-07T02:18:30Z

On Fri 04 Mar 07:52 CST 2022, Andy Shevchenko wrote:

> On Fri, Mar 04, 2022 at 03:41:33PM +0200, Sakari Ailus wrote:
> > On Fri, Mar 04, 2022 at 02:54:21PM +0200, Andy Shevchenko wrote:
> > > On Thu, Mar 03, 2022 at 02:33:46PM -0800, Bjorn Andersson wrote:
>
> ...
>
> > > > + if (count >= matches_len && matches) {
> > > > + fwnode_handle_put(ep);
> > > > + return count;
> > > > + }
> > >
> > > Wouldn't be the same as
> > >
> > > if (count >= matches_len) {
> > > fwnode_handle_put(ep);
> > > break;
> > > }
> >
> > Don't you need to check for non-NULL matches here?
>
> Right, this should be kept as in original patch.
>
> > I find return above easier to read.
>
> Okay, original code may work, so I have no strong opinion about return vs
> break, although I find slightly better to have a single point of return in
> such case.
>

I like using early returns when possible, but this is not an early
return and it is in the loop so it makes more sense to me to break out.

> > > ?
>
> ...
>
> > > > + count_graph = fwnode_graph_devcon_matches(fwnode, con_id, data, match,
> > > > + matches, matches_len);
> > >
> > > > + matches += count_graph;
> > > > + matches_len -= count_graph;
> > >
> > > No, won't work when matches == NULL.
> > >
> > > Also, matches_len is expected to be 0 in that case (or at least being ignored,
> > > check with vsnprintf() behaviour in similar case).
> > >
> > > So, something like this, perhaps
> > >
> > > if (matches && matches_len) {
> > > matches += count_graph;
> > > matches_len -= count_graph;
> > > }
> >
> > Good find!
>
> I have checked vsnprintf() and indeed, it expects to have the size is 0 when
> the resulting buffer pointer is NULL, and it doesn't do any additional checks.
>

Per the vsnprintf() semantics it's not the destination buffer being NULL
that's significant, but rather just the length being 0 that matters.

To follow that, I should fill @matches_len entries in @matches and then
just continue counting without storing anything in @matches.

But that won't work in this case, because in the event that the @match
function returns something that has to be freed (such as the refcounted
objects returned by the typec_mux code), dropping this in favor of just
counting it would cause memory/reference leaks.

As such, I think this should differ in that @matches = NULL is
significant, and it's nice to not have matches_len turn negative/bogus
in the count case.

So I like your suggestion.

Thanks,
Bjorn

> > > > + count_ref = fwnode_devcon_matches(fwnode, con_id, data, match,
> > > > + matches, matches_len);
>
> --
> With Best Regards,
> Andy Shevchenko
>
>