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 74E1DC433FE for ; Sun, 2 Oct 2022 19:34:52 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C5D6284904; Sun, 2 Oct 2022 21:34:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=suse.de 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=suse.de header.i=@suse.de header.b="1J0SweE2"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="+viKQH4P"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C89F18499D; Sun, 2 Oct 2022 21:34:47 +0200 (CEST) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2465484904 for ; Sun, 2 Oct 2022 21:34:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=msuchanek@suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id C9CE0218D6; Sun, 2 Oct 2022 19:34:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1664739284; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ohRp5jiMtVr2rAC0BzuOL+1YvfYyICyLct4bPRGv8JA=; b=1J0SweE2xqJxf8RyX4uCgSouirp+Iaa9RSaHMMgcsO2R4bhIdneEzG267WHILe9ih0KbBA kfbidtOsDH3dazNLthpAXtmN0z8Va2loV2vTKpsL76c95Fc027PwMOcdA2TgeXYqxXlVWg o5a2C0XhGhwDmo+IYgzkH/CYZjxgMbM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1664739284; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ohRp5jiMtVr2rAC0BzuOL+1YvfYyICyLct4bPRGv8JA=; b=+viKQH4PjFraP0rTTsDCXARckbl7Dl23Zsr2c8gej5Chcv33jwMsF+ynVlzZ6i3b5QWB5f dJRnixbhX91lmNAg== Received: from kitsune.suse.cz (kitsune.suse.cz [10.100.12.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A690C2C141; Sun, 2 Oct 2022 19:34:44 +0000 (UTC) Date: Sun, 2 Oct 2022 21:34:43 +0200 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Simon Glass Cc: U-Boot Mailing List , Heinrich Schuchardt , AKASHI Takahiro , Bin Meng , Stefan Roese Subject: Re: [PATCH v4 04/21] dm: blk: Add probe in blk_first_device/blk_next_device Message-ID: <20221002193443.GC28810@kitsune.suse.cz> References: <76875ef0301a144797b7aee456ecb0a699a0418f.1664093812.git.msuchanek@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 On Thu, Sep 29, 2022 at 04:00:26AM -0600, Simon Glass wrote: > Hi Michal, > > On Sun, 25 Sept 2022 at 02:28, Michal Suchanek wrote: > > > > The description claims that the device is probed but it isn't. > > > > Add the device_probe() call. > > > > Also consolidate the iteration into one function. > > > > Fixes: 8a5cbc065d ("dm: blk: Use uclass_find_first/next_device() in blk_first/next_device()") > > Signed-off-by: Michal Suchanek > > --- > > drivers/block/blk-uclass.c | 46 ++++++++++++++++++-------------------- > > 1 file changed, 22 insertions(+), 24 deletions(-) > > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c > > index 21c5209bb6..992f8ad3da 100644 > > --- a/drivers/block/blk-uclass.c > > +++ b/drivers/block/blk-uclass.c > > @@ -361,45 +361,43 @@ int blk_dselect_hwpart(struct blk_desc *desc, int hwpart) > > return blk_select_hwpart(desc->bdev, hwpart); > > } > > > > -int blk_first_device(int if_type, struct udevice **devp) > > +static int _blk_next_device(int if_type, struct udevice **devp) > > { > > struct blk_desc *desc; > > - int ret; > > + int ret = 0; > > + > > + for (; *devp; uclass_find_next_device(devp)) { > > + desc = dev_get_uclass_plat(*devp); > > + if (desc->if_type == if_type) { > > + ret = device_probe(*devp); > > + if (!ret) > > + return 0; > > + } > > + } > > > > - ret = uclass_find_first_device(UCLASS_BLK, devp); > > if (ret) > > return ret; > > - if (!*devp) > > - return -ENODEV; > > - do { > > - desc = dev_get_uclass_plat(*devp); > > - if (desc->if_type == if_type) > > - return 0; > > - ret = uclass_find_next_device(devp); > > - if (ret) > > - return ret; > > - } while (*devp); > > This looks wrong since a media device may have other devices under it, > e.g. UCLASS_BOOTDEV so I think you should keep the existing code and > just call uclass_probe() at the end. > > You could add a test for this by checking that only the BLK device is probed. The description says that it returns ready to use device, and that's not possible when the device is only probed at the end when it is to be returned. There are some tests of this function but very few users so it may be OK to change the semantic again to resemble the _check variant uclass iterator and retorn broken devices but I don't think that was the intent here with using uclass_first_device/uclass_next_device originally. Also this change only makes a difference to the amount of devices probed for callers that only call the blk_first_device and never move on to the next. Callers that use the functions for iteration will move on to the next device and probe it anyway. Thanks Michal