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 CAD0DC433EF for ; Wed, 20 Apr 2022 02:50:16 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A912E83D60; Wed, 20 Apr 2022 04:50:13 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com 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=konsulko.com header.i=@konsulko.com header.b="FS4J5yWX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 02F4883D7A; Wed, 20 Apr 2022 04:50:12 +0200 (CEST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 C738283C70 for ; Wed, 20 Apr 2022 04:50:08 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x832.google.com with SMTP id f14so154608qtq.1 for ; Tue, 19 Apr 2022 19:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ML/ZP8TqJtkIaSy2YZl1vO6TJcdN1YZ9xxJbfke2ijg=; b=FS4J5yWXJCqwzrpOoqV9kazi+SIu1tnCk87763gfFbYkF00ktkuCfvT95U3r4bBo4T lKUgUNzxWjiiySF2+rkj6hrmmeCvzs2b22OvxUQZYN+CgEEde+D2rnjb6Vwp3a1I4IlK 7xXZHinwYhzktsjq68OjOxv8Rk4lLFviQ+eIE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ML/ZP8TqJtkIaSy2YZl1vO6TJcdN1YZ9xxJbfke2ijg=; b=hOxhApyLmxS3r0nd7sx3F1KQycDZOsKvFMnemel4wiMabvPrzItrW3d4AEsJ+IFFzN 9CeNPnAnnoeGpJfWuuvcdK+k0xvvo2etrHCpJ0Bfz2UBFwuqfgyuMTcADXzUoybumoyK TyP/VhSvZ1mFe4Wcg2XHe5lFZu3aAeS8ABIoRTJ2hPfMRgJ1TQpQrBFxUrTalyUa95ho wiBZVemKGi9idjEDvMKgkUSgfmGjEmaotJyWaNxF20m3hGXEIZIR4c0hAxF1zdu7ukl7 pRc0L0TJDX0YII++Xp9ZFqOVnpxdxpPbYhNL3EKin90bufEPOSQUGfzDGfWGKPxDBN2t kT1g== X-Gm-Message-State: AOAM532TZLuUlT1mu7BmS4ZjpeH1PuqV9bhXfjdq4VwT3gNEhVBW9/Ti n8KkkvsPgSd/Z3ylOht4DpXdpA== X-Google-Smtp-Source: ABdhPJxFW5hJ5yhpum6rD9VkFd2C+uXNemH8UfMIDsF3vFfA1cPWSVD+/5PYdJYBgYnneUj5FTf/Hw== X-Received: by 2002:ac8:5f13:0:b0:2f1:f414:e037 with SMTP id x19-20020ac85f13000000b002f1f414e037mr12058140qta.257.1650423007510; Tue, 19 Apr 2022 19:50:07 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id u5-20020a05622a198500b002f1f02b7465sm1050929qtc.17.2022.04.19.19.50.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 19:50:06 -0700 (PDT) Date: Tue, 19 Apr 2022 22:50:04 -0400 From: Tom Rini To: AKASHI Takahiro , sjg@chromium.org, xypron.glpk@gmx.de, u-boot@lists.denx.de Subject: Re: [PATCH 3/7] disk: define nullified functions for !PARTITIONS Message-ID: <20220420025004.GY3045430@bill-the-cat> References: <20220419010158.47034-1-takahiro.akashi@linaro.org> <20220419010158.47034-4-takahiro.akashi@linaro.org> <20220419030938.GE3045430@bill-the-cat> <20220419041123.GA51109@laputa> <20220419121207.GF3045430@bill-the-cat> <20220420021721.GB56861@laputa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sDhuxz86kt5qlkuV" Content-Disposition: inline In-Reply-To: <20220420021721.GB56861@laputa> X-Clacks-Overhead: GNU Terry Pratchett 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.5 at phobos.denx.de X-Virus-Status: Clean --sDhuxz86kt5qlkuV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 20, 2022 at 11:17:21AM +0900, AKASHI Takahiro wrote: > Hi Tom, >=20 > On Tue, Apr 19, 2022 at 08:12:07AM -0400, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 01:11:23PM +0900, AKASHI Takahiro wrote: > > > On Mon, Apr 18, 2022 at 11:09:38PM -0400, Tom Rini wrote: > > > > On Tue, Apr 19, 2022 at 10:01:54AM +0900, AKASHI Takahiro wrote: > > > >=20 > > > > > Some defconfig enables CMD_PART even if none of any partition tab= le > > > > > types (CONFIG_*_PARTITION) are enabled. > > > > > This will lead to the size growth in SPL/TPL code since disk/part= =2Ec > > > > > will be compiled in any way. > > > > > We will change disk/Kconfig later so that CONFIG_PARTITIONS is on= ly > > > > > enabled when, at least, one of CONFIG_*_PARTITION is enabled. > > > > >=20 > > > > > To make the build work (in particular, "part" command) correctly, > > > > > a few functions should be defined as void functions in case of > > > > > !CONFIG_PARTITIONS. > > > > >=20 > > > > > Signed-off-by: AKASHI Takahiro > > > >=20 > > > > I guess I wonder why we don't just make CMD_PART depend on PARTITIO= NS > > > > now and thus correct the few (single?) board that has this enabled > > > > without underlying partition code by removing the can't be function= al > > > > cmd. > > >=20 > > > Well, that is partially what I did in my RFC and I thought > > > that you declined to accept my change. > > > Did I misunderstand you? > >=20 > > Yes, I wasn't clear, sorry for the confusion. Just this part of the > > series should be replaced with making CMD_PART depend on PARTITIONS and > > if there really is a use case for 'part' without PARTITION support > > (rather than it being an unintentionally enabled feature) we can deal > > with it then. The rest of the series looks good to me and I'll let > > Heinrich comment on the EFI specific parts. >=20 > I do understand what you expect here, but, what I call, "nullified > function" technique is already used in several places. > For instance, take blk_get_device_part_str() function which has > a nullified version of definition in include/part.h. > It is used without explicit dependency on CONFIG_PARTITIONS at: > cmd/zfs.c > cmd/disk.c > cmd/reiser.c > cmd/fat.c > env/ext4.c > env/fat.c >=20 > So I would like to propose to create another patch that you expect (and > what I did in RFC) instead of removing this patch because the latter > has no negative effect. >=20 > If you agree, I will post it as a separate patch. OK, lets go with that then, thanks! --=20 Tom --sDhuxz86kt5qlkuV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmJfdNkACgkQFHw5/5Y0 tywUtwwAhaGR/FTtiqKsYCN7skjjaU4n+uQz4GkLVn16qvfMSirGtZ7y5ATegBGv 0iNN26XHCkwvHYsY8lCq6LcciWmvZZ/npy7hkKm6rbz9vztzb6jaYB3YxX4a02GT YT+dYXbTSghgIrY2eXIKlRUeo6smMSpTWOaVfNOy++t5ALFUSala6fLrTiS+TJkZ 4+6/Bwnsi87Pn9zQESo2HCyUqVBLlzOEXa9iXK6mLh+d+CWkEHgFogWnMNnhqXyf 0CqdSBP6ZI06+c9SxKgvq9S9xtGd7N005kWQ2ZdB61UxvDjZyl+H08GR+PokaV1F 2YY/lM5vefEYi2DBmYVR+VTbGP0Al9LgDBQ2YFXArjTZkO7WsSbRXPVPaR6vV35w K8ghc+gMBaZ/qtO3iO0o4SKoiapOEDQE2jKAoAvZ/wGnNrbuJL8LBNveKmXL7NbA JCd7KM93qX2z19IHp92cSsXM1bbdFnOhIjXIDVVqUV3EVft9j0ft6ENcjLpAo2N0 EX9MyD4o =UmOx -----END PGP SIGNATURE----- --sDhuxz86kt5qlkuV--