Re: [PATCH v3] dm: core: Do not stop uclass iteration on error

From: Simon Glass <sjg@chromium.org>
To: "Michal Suchánek" <msuchanek@suse.de>
Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>,
	"Marek Vasut" <marex@denx.de>,
	"Viktor Křivák" <viktor.krivak@gmail.com>,
	"Pavel Herrmann" <morpheus.ibis@gmail.com>,
	"Tomas Hlavacek" <tmshlvck@gmail.com>
Subject: Re: [PATCH v3] dm: core: Do not stop uclass iteration on error
Date: Tue, 30 Aug 2022 21:15:12 -0600	[thread overview]
Message-ID: <CAPnjgZ3EGKfQ7op-zC+-skaY3KV51vQOypX-p+ernSkgsnzfLw@mail.gmail.com> (raw)
In-Reply-To: <20220830164810.GP28810@kitsune.suse.cz>

Hi Michal,

On Tue, 30 Aug 2022 at 10:48, Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Tue, Aug 30, 2022 at 09:56:52AM -0600, Simon Glass wrote:
> > Hi Michal,
> >
> > On Tue, 30 Aug 2022 at 04:23, Michal Suchánek <msuchanek@suse.de> wrote:
> > >
> > > On Sat, Aug 27, 2022 at 07:52:27PM -0600, Simon Glass wrote:
> > > > Hi Michal,
> > > >
> > > > On Fri, 19 Aug 2022 at 14:23, Michal Suchanek <msuchanek@suse.de> wrote:
> > > > >
> > > > > When probing a device fails NULL pointer is returned, and other devices
> > > > > cannot be iterated. Skip to next device on error instead.
> > > > >
> > > > > Fixes: 6494d708bf ("dm: Add base driver model support")
> > > >
> > > > I think you should drop this as you are doing a change of behaviour,
> > > > not fixing a bug!
> > >
> > > You can hardly fix a bug without a change in behavior.
> > >
> > > These functions are used for iterating devices, and are not iterating
> > > devices. That's clearly a bug.
> >
> > If it were clear I would have changed this long ago. The new way you
> > have this function ignores errors, so they cannot be reported.
> >
> > We should almost always report errors, which is why I think your
> > methods should be named differently.
> >
> > >
> > > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > > > > ---
> > > > > v2: - Fix up tests
> > > > > v3: - Fix up API doc
> > > > >     - Correctly forward error from uclass_get
> > > > >     - Do not return an error when last device fails to probe
> > > > >     - Drop redundant initialization
> > > > >     - Wrap at 80 columns
> > > > > ---
> > > > >  drivers/core/uclass.c | 32 ++++++++++++++++++++++++--------
> > > > >  include/dm/uclass.h   | 13 ++++++++-----
> > > > >  test/dm/test-fdt.c    | 20 ++++++++++++++++----
> > > > >  3 files changed, 48 insertions(+), 17 deletions(-)
> > > >
> > > > Unfortunately this still fails one test. Try 'make qcheck' to see it -
> > > > it is ethernet.
> > >
> > > I will look at that.
> > >
> > > > I actually think you should create new functions for this feature,
> > > > e.g.uclass_first_device_ok(), since it makes it impossible to see what
> > > > when wrong with a device in the middle.
> > > >
> > > > I have long had all this in my mind. One idea for a future change is
> > > > to return the error, but set dev, so that the caller knows there is a
> > > > device, which failed. When we are at the end, dev is set to NULL.
> > >
> > > We already have uclass_first_device_check() and
> > > uclass_next_device_check() to iterate all devices, including broken
> > > ones, and getting the errors as well.
> > >
> > > That's for the case you want all the details, and these are for the case
> > > you just want to get devices and don't care about the details.
> > >
> > > That's AFAICT as much as this iteration interface can provide, and we
> > > have both cases covered.
> >
> > I see three cases:
> > - want to see the next device, returning the error if it cannot be
> > probed - uclass_first_device()
>
> And the point of this is what exactly?

Please can you adjust your tone, It seems too aggressive for this
mailing list. Thank you.

>
> The device order in the uclass is not well defined - at any time a new
> device which will become the first can be added, fail probe, and block
> what was assumed a loop iterating the uclass from returning any devices
> at all. That's exactly what happened with the new sysreset.

The order only changes if the device is unbound and rebound. Otherwise
the order set by the device tree is used.

>
> What is exactly the point of returning the error and not the pointer to
> the next device?

Partly, we have existing code which uses the interface, checking 'dev'
to see if the device is valid. I would be happy to change that, so
that the device is always returned. In fact I think it would be
better. But it does need a bit of work with coccinelle, etc.

>
> The only point of these simplified iterators is that the caller can
> check only one value (device pointer) and then not check the error
> because they don't care. If they do cate uclass_first_device_check()
> provides all the details available.

Yes I think we can have just two sets of iterators, but in that case
it should be:

- want to see the next device, returning the error if it cannot be
probed, with dev updated to the next device in any case - new version
of uclass_first_device() - basically rename
uclass_first_device_check() to that
- want to see next device which probes OK - your new function, perhaps
uclass_first_device_ok() ?

>
> > - want to get the next device that can successfully probe - your new functions
> > - want to see each device, along with any errors - uclass_first_device_check()

Regards,
SImon