Re: [PATCH v1] reset: Make optional stuff optional for all users

[Philipp Zabel]

On Mon, 2017-04-03 at 18:23 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-03 at 17:09 +0200, Philipp Zabel wrote:
> > On Mon, 2017-04-03 at 14:33 +0000, Shevchenko, Andriy wrote:
> > > On Mon, 2017-04-03 at 17:31 +0300, Andy Shevchenko wrote:
> > > > On Mon, 2017-04-03 at 16:27 +0200, Philipp Zabel wrote:
> > > > > 
> > > > > >  	int rstc_id;
> > > > > >  	int ret;
> > > > > >  
> > > > > > -	if (!node)
> > > > > > -		return ERR_PTR(-EINVAL);
> > > > > > -
> > > > > 
> > > > > This should be
> > > > > 
> > > > > 	if (!node)
> > > > > 		return optional ? NULL : ERR_PTR(-EINVAL);
> > > > > 
> > > > > instead. Can you confirm this works for Intel boards with DW
> > > > > UART? I
> > > > > can
> > > > > fix it up when applying if you agree.
> > > > 
> > > > I don't think it worth to change. I specifically checked all of_*
> > > > calls
> > > > in that function and they cope pretty nice with node == NULL.
> > 
> > __of_reset_control_get called with id != NULL calls
> > of_property_match_string first, which then returns -EINVAL if
> > node == NULL, which makes __of_reset_control_get return NULL if
> > optional
> > or -ENOENT otherwise, even though the correct return value would be
> > -EINVAL in the DT case.
> 
> Error handling mess as usual. :-)
>
> > 
> > __of_reset_control_get called with id == NULL calls
> > of_parse_phandle_with_args first, which calls
> > __of_parse_phandle_with_args, which returns an undefined value if
> > np == NULL, as far as I can tell:
> > of_for_each_phandle first calls of_phandle_iterator_init, which, when
> > called with np == NULL clears the iterator structure returns -ENOENT.
> > The return value is ignored in the of_for_each_phandle macro, and
> > of_phandle_iterator_next is then called and returns -ENOENT because
> > it->cur == NULL, ending the loop without ever assigning a value to rc.
> > __of_parse_phandle_with_args then returns the uninitialized value.
> 
> It returns -ENOENT. Error value is kept in function variable rc.

Thanks for the correction. That's still the wrong error code IMHO, but
it certainly makes your patch unproblematic.

> > The point being, instead of having to regularly forage through a
> > number
> > of of_ API functions to make sure my expectations are still met, I'd
> > prefer to keep the check in place.
> 
> I would not insist, I already shared my view on this.

Appreciated. With a correct understanding of the current of_* error
return paths it makes a lot more sense.

> I really don't like ping-ponging of the code. Perhaps you would fix it
> once for the best now?

How about:

----------8<----------