[PATCH] pci: Fix device_find_first_child() return value handling
Michal Suchánek
msuchanek at suse.de
Thu Jul 27 08:42:55 CEST 2023
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 <marex at 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
More information about the U-Boot
mailing list