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 8024DC433F5 for ; Wed, 20 Apr 2022 02:17:35 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E78A483E3E; Wed, 20 Apr 2022 04:17:31 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="eMyZZiH6"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DAFB683AB6; Wed, 20 Apr 2022 04:17:29 +0200 (CEST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 92122833D7 for ; Wed, 20 Apr 2022 04:17:26 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pj1-x102b.google.com with SMTP id j8-20020a17090a060800b001cd4fb60dccso603426pjj.2 for ; Tue, 19 Apr 2022 19:17:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=qxDq0akOWMw/tPmlPdsk5gGZ9rufoYr/j+sW+SwWjFg=; b=eMyZZiH6s0vOxR21ME5lNR7tJN5DtBG6ZEkVQXKCUAXSXv83TEOQhy6ULCGGl0hlk4 QHNHJ/ykihCtGp3GXPDg9s4NF6ioURKW8iY2VVPnPvkEaa4FLu51/2t1LkVS1/bHEvzP CzCLB/ioxSIr16Z3uTDiznZkBiuuhdwEknAC+O9ztNhnpQctDn3O3FVZWYjluUW57OZ8 fpVrrqGIpip5DqM6AxcCnsQ467LDUrXvGSSSbm1LGZfGvUhVcvXiWQvEs7YStU4sLB58 siuFJxLiyUg7z3uaQJv0z2AD/d7DoAKmyMapqAx7unhfWfbdY5eYdqOWeGXN2prl+/Vk 8z+Q== 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:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=qxDq0akOWMw/tPmlPdsk5gGZ9rufoYr/j+sW+SwWjFg=; b=f+635zXnH3VFKJHHctjWQy2NnWb4g4cnNa0aPY+rwHiOJzCWw3eYNiIHJ7HnGxPd4r ojxJbBtjEX/RHq50H1Ct3CIvPXLtT0wW1S7QI5XjNPD0OmZkYr/85fUmeLgr7Oj4o/T9 t/IW88oIHpDfztQeOsYxBHIU4NioOUfjZKw31IMYbGH14D5lqwOxZYQAQttveNnWgYnW /UdFCmaWuPaG6FSnD3azN319RFQ985NZOA1ZCsk4DpcAiLgV2c86VC83D5Sxu0cEWqcY aSHlfz19fx1X5dAjKGxeGH6SMC+U6Jbcyj2FI5Ey/JrX/1U/vRFPhmP4hvKt0QgzIGaV RKKw== X-Gm-Message-State: AOAM532vGTdBeoNKeoncjPf+0MBntuGZcvm6gVb4JeS0IGfs42tBY0Xo gjkMLafoXUTKDZVc5DDzOQQm/w== X-Google-Smtp-Source: ABdhPJwOJH0LtLr1DQQjFdLxRrvmG+yWPssWm0RxLiEXcdPm2xEgGqOD7QgZc8oxddI3u0rNMFcMmQ== X-Received: by 2002:a17:902:d88a:b0:156:1609:1e62 with SMTP id b10-20020a170902d88a00b0015616091e62mr18573393plz.143.1650421044874; Tue, 19 Apr 2022 19:17:24 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:608b:531f:af75:16d6]) by smtp.gmail.com with ESMTPSA id i6-20020a17090a718600b001d27a7d1715sm9448482pjk.21.2022.04.19.19.17.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 19:17:24 -0700 (PDT) Date: Wed, 20 Apr 2022 11:17:21 +0900 From: AKASHI Takahiro To: Tom Rini Cc: 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: <20220420021721.GB56861@laputa> Mail-Followup-To: AKASHI Takahiro , Tom Rini , sjg@chromium.org, xypron.glpk@gmx.de, u-boot@lists.denx.de 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220419121207.GF3045430@bill-the-cat> 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 Hi Tom, 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: > > > > > > > Some defconfig enables CMD_PART even if none of any partition table > > > > types (CONFIG_*_PARTITION) are enabled. > > > > This will lead to the size growth in SPL/TPL code since disk/part.c > > > > will be compiled in any way. > > > > We will change disk/Kconfig later so that CONFIG_PARTITIONS is only > > > > enabled when, at least, one of CONFIG_*_PARTITION is enabled. > > > > > > > > To make the build work (in particular, "part" command) correctly, > > > > a few functions should be defined as void functions in case of > > > > !CONFIG_PARTITIONS. > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > > I guess I wonder why we don't just make CMD_PART depend on PARTITIONS > > > now and thus correct the few (single?) board that has this enabled > > > without underlying partition code by removing the can't be functional > > > cmd. > > > > Well, that is partially what I did in my RFC and I thought > > that you declined to accept my change. > > Did I misunderstand you? > > 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. 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 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. If you agree, I will post it as a separate patch. -Takahiro Akashi > -- > Tom