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

[Bjorn Andersson <bjorn.andersson@linaro.org>]

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