From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 423B2C54EE9 for ; Sat, 17 Sep 2022 15:03:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1546184873; Sat, 17 Sep 2022 17:03:11 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="dUKU6Uuv"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9F061843F0; Sat, 17 Sep 2022 17:03:09 +0200 (CEST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E0BB8845F4 for ; Sat, 17 Sep 2022 17:03:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-yb1-xb36.google.com with SMTP id p69so29954497yba.0 for ; Sat, 17 Sep 2022 08:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=SvSO+KrYOeUP7vD3R3KwOTw52INPXV7fP4H0LJ5XgPI=; b=dUKU6UuvNX/Ub77YFtB3n/7/Iv0zBdr63lZ4nZC/Ca2y8PRmL7cs269+OJDqr1y9ns fDz43sCwl2eumfYBY24rfWzEzPdxk0r0lZGCBrkkPAAw3CrTaCij8Xn0btHSgGDqdHjm cBktv+qVELsZ61nRRlbpvGDtk09ZytTI+MOtg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=SvSO+KrYOeUP7vD3R3KwOTw52INPXV7fP4H0LJ5XgPI=; b=GDFfuapzKq3p6JNbIr/cNEPDVevbrQBts8v8Z+1J/Q3zJ11PnpU4BGgqD3boFlBeO9 w7oblHFPGA+uUw1aWF8yWDnlJ53L2SjcoJnOAFzr/yxg7q/Gp2+kAXxsYE8LvfP5wzMW Lb3bsip1RptBMnEqbXS1fIoBJOfxAEz/TNVd3rZG7THznfzMOYgUDlOPPNlS0QXgDuiL 6asBJHMdTjXAjM5fX6x8YDkGCsnfjPK8V7ZX9ulYmZ4RrLBABEXifXzPKhrwIdCzyvwc xM6z9HNEmQvzi2v8BN4EjRHSLxE4A+l5RBEAPJGm0dCOGyFYrm3Frt/Mm4c6PnSkzBWY 1Lzw== X-Gm-Message-State: ACrzQf3Gaeo2594yOIN2kzZN1rmxUAyQCUdR8C3YUIq+/u12Ibk6e/k8 zHxHu9ctC9rpQeYkadBxRR4CxVpc7f/p+FWlXVffuQ== X-Google-Smtp-Source: AMsMyM4Z/g5hLGFxDOvJBdmWLCgEpMT6ODyyeHBYn5BmvvGqSzieDtbyQkUP0miJ2p4yNG+ZdxVAYLvpVu1pK94HXcE= X-Received: by 2002:a25:846:0:b0:6a8:c5de:3e37 with SMTP id 67-20020a250846000000b006a8c5de3e37mr8364341ybi.412.1663426985134; Sat, 17 Sep 2022 08:03:05 -0700 (PDT) MIME-Version: 1.0 References: <20220818194640.GC28810@kitsune.suse.cz> <20220819202322.25701-1-msuchanek@suse.de> <20220830102303.GO28810@kitsune.suse.cz> <20220830164810.GP28810@kitsune.suse.cz> <20220831073903.GQ28810@kitsune.suse.cz> In-Reply-To: From: Simon Glass Date: Sat, 17 Sep 2022 09:02:53 -0600 Message-ID: Subject: Re: [PATCH v3] dm: core: Do not stop uclass iteration on error To: =?UTF-8?Q?Michal_Such=C3=A1nek?= Cc: U-Boot Mailing List , Marek Vasut , =?UTF-8?B?VmlrdG9yIEvFmWl2w6Fr?= , Pavel Herrmann , Tomas Hlavacek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Michal, On Wed, 31 Aug 2022 at 11:44, Simon Glass wrote: > > Hi Michal, > > On Wed, 31 Aug 2022 at 01:39, Michal Such=C3=A1nek wr= ote: > > > > Hello, > > > > On Tue, Aug 30, 2022 at 09:15:12PM -0600, Simon Glass wrote: > > > Hi Michal, > > > > > > On Tue, 30 Aug 2022 at 10:48, Michal Such=C3=A1nek 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=C3=A1nek 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 wrote: > > > > > > > > > > > > > > > > When probing a device fails NULL pointer is returned, and o= ther 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 beh= aviour, > > > > > > > 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 ite= rating > > > > > > 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 > > > > > > > > --- > > > > > > > > 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 prob= e > > > > > > > > - 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 fea= ture, > > > > > > > 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 ch= ange is > > > > > > > to return the error, but set dev, so that the caller knows th= ere is a > > > > > > > device, which failed. When we are at the end, dev is set to N= ULL. > > > > > > > > > > > > We already have uclass_first_device_check() and > > > > > > uclass_next_device_check() to iterate all devices, including br= oken > > > > > > 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 b= e > > > > > 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 bl= ock > > > > what was assumed a loop iterating the uclass from returning any dev= ices > > > > at all. That's exactly what happened with the new sysreset. > > > > > > The order only changes if the device is unbound and rebound. Otherwis= e > > > the order set by the device tree is used. > > > > So the order is defined by device tree. That does not make it > > well-defined from the point of view of any kind of code. > > > > The point of device tree is that it can be replaced with another device > > tree describing another board and the code should still work. Otherwise > > we would not need device trees, and could keep using board files. > > We do use the raw ordering in test code, but in general we use the > sequence number (from DT ordering or aliases) to provide the official > ordering (the uclass...seq() calls). > > > > > > > What is exactly the point of returning the error and not the pointe= r 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. > > > > I suppose changing the return type to void would catch the users that d= o > > something with the return value but it would still need building all > > the code. > > > > And it does not work for users of uclass_first_device_err which is > > basically useless after this change but pretty much all users use the > > return value. > > > > > > 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 > > > > About 2/3 of users of uclass_first_device don't use the return value at > > all in current code. Changing uclass_first_device to > > uclass_first_device_check is counterproductive. The current > > documentation basically implies the new behavior, and there are a lot o= f > > examples in the core code that use uclass_first_device in a for loop > > without assigning the return value at all. > > > > Also renaming uclass_first_device_check would break the 3 existing user= s > > of it. > > > > > - want to see next device which probes OK - your new function, perhap= s > > > uclass_first_device_ok() ? > > > > I don't think any amount of renaming is going to solve the problem at > > hand: we have bazillion of users of uclass_first_device, and because it > > was not documented that it does not in fact iterate uclass devices ther= e > > are users that use it for the purpose. There are also users that expect > > maningful return value which is basically bogus - they do get a return > > value of something, but not something specific. > > > > What can be done is adding the simple iterator under new name, convert > > the obvious existing users, and mark the old function deprecated in som= e > > way so that any code that uses it generates a warning. > > I'm OK with that. But let's rename uclass_first_device() to > uclass_old_first_device() or something like that. Just wondered if you have had time to respin this? -next is open and I'd like to apply this soon so we have maximal testing ti= me. Regards, Simon