Hello, On Wed, Jul 26, 2023 at 06:49:57PM -0600, Simon Glass wrote: > Hi Marek, > > On Mon, 17 Jul 2023 at 11:03, Marek Vasut <ma...@denx.de> wrote: > > > > On 7/17/23 09:42, Michal Suchánek wrote: ... > > > More generally, what is the overall vision for these functions returning > > > always zero? > > > > > > Should the return value be kept in case the underlying implementation > > > changes and errors can happen in the future, and consequently checked? > > > > > > Should the return value be removed when meaningless making these > > > useless assignments and checks an error? > > > > > > I already elimimnated a return value where using it lead to incorrect > > > behavior but here using it or not is equally correct with the current > > > implementation. > > > > Probably a question for Simon, really. Personally I would be tempted to > > switch the function to return void. > > So long as the function has its meaning documented, I think it is OK. > As a separate patch, I am OK with changing > device_find_first/next_child() to void, or alternatively having them > return 0 on success and -ENODEV if nothing was found.
I think when there is one error condition having two ways to report it is one too many. Thanks Michal
