On Mon, May 17, 2021 at 6:14 PM Bjorn Andersson
<bjorn.andersson@xxxxxxxxxx> wrote:
> On Mon 17 May 04:13 CDT 2021, Andy Shevchenko wrote:
> > On Sun, May 16, 2021 at 6:47 AM Bjorn Andersson
> > <bjorn.andersson@xxxxxxxxxx> wrote:
> > >
> > > In typec_mux_match() "nval" is assigned the number of elements in the
> > > "svid" fwnode property, then the variable is used to store the success
> > > of the read and finally attempts to loop between 0 and "success" - i.e.
> > > not at all - and the code returns indicating that no match was found.
> > >
> > > Fix this by using a separate variable to track the success of the read,
> > > to allow the loop to get a change to find a match.
...
> > > - nval = fwnode_property_read_u16_array(fwnode, "svid", val, nval);
> > > - if (nval < 0) {
> > > + ret = fwnode_property_read_u16_array(fwnode, "svid", val, nval);
> > > + if (ret < 0) {
> > > kfree(val);
> > > - return ERR_PTR(nval);
> > > + return ERR_PTR(ret);
> > > }
> >
> > This changes the behaviour of the original code, i.e. nval can be
> > still positive but less than we got from previous call. Some fwnode
> > backends in some cases potentially can _successfully_ read less than
> > asked.
> >
> > Perhaps
> >
> > nval = ret;
> >
> > or drop the patch.
> >
>
> Per the kerneldoc of fwnode_property_read_u16_array:
>
> * Return: number of values if @val was %NULL,
> * %0 if the property was found (success),
>
> @val is not NULL, as we just checked for that, so the function will
> always return 0 on success.
>
> I don't see anything indicating that the number of elements can be
> different from what fwnode_property_count_u16() returned.
Okay, I have checked the backends of fwnode and indeed, OF case (from
where I remember such behaviour) deliberately does
if (ret >= 0)
return 0;
Otherwise the rest return 0 directly / explicitly.
The only exception is _read_string_array().
> > > for (i = 0; i < nval; i++) {
--
With Best Regards,
Andy Shevchenko
