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 979ABEB64DD for ; Thu, 27 Jul 2023 06:43:05 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 9833386373; Thu, 27 Jul 2023 08:43:03 +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="WpCnb/sJ"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="nR/Fq37H"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9196484782; Thu, 27 Jul 2023 08:43:01 +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 5A29386373 for ; Thu, 27 Jul 2023 08:42:57 +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 21C2C21ACD; Thu, 27 Jul 2023 06:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1690440177; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7QRURPUoybE0tShL3k6LKLUQC8POK80wGvep/0makwM=; b=WpCnb/sJ3pbCZ3+MQtqWoPhI9YZBm6IEg3WPPedC5yj/k+4yZHKI1PHZ4iWG3Ips8B6iz5 QO7GJh9iB+zWY2YIdoLWbz7o4pBmJnOCbhljNHweVzczinC+KnIWTfTwU9Nhso0ZTyBLmd Bc6c+sA2eSUBcUx0NW2+JuEU+toK5cg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1690440177; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7QRURPUoybE0tShL3k6LKLUQC8POK80wGvep/0makwM=; b=nR/Fq37HcnRwln1XxHSkQQu1GHEo9zs3lcFmfaT8VRNzHx3AXGIuY/ZuXPLp92yxdQE3Cr A4R0XPooeBIF8CAA== 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 D3E8F2C142; Thu, 27 Jul 2023 06:42:56 +0000 (UTC) Date: Thu, 27 Jul 2023 08:42:55 +0200 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Simon Glass Cc: Marek Vasut , u-boot@lists.denx.de, Jonas Karlman , Pali =?iso-8859-1?Q?Roh=E1r?= , Bin Meng Subject: Re: [PATCH] pci: Fix device_find_first_child() return value handling Message-ID: <20230727064255.GN9196@kitsune.suse.cz> References: <20230716155324.11211-1-marex@denx.de> <20230717074233.GP9196@kitsune.suse.cz> <740466a1-8d08-925f-17e1-b714e6d490c5@denx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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.8 at phobos.denx.de X-Virus-Status: Clean 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 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