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 3116FC433F5 for ; Tue, 14 Dec 2021 13:01:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 97E0D80FD9; Tue, 14 Dec 2021 14:01:16 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.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=kernel.org header.i=@kernel.org header.b="TUciysoX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 70FB380FF4; Tue, 14 Dec 2021 14:01:14 +0100 (CET) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5311180D1C for ; Tue, 14 Dec 2021 14:01:10 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=kabel@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E8B9CB818CC; Tue, 14 Dec 2021 13:01:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79001C34605; Tue, 14 Dec 2021 13:01:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639486868; bh=Mf8ub8pudzewDC0OyzHUiwqXHiHXzULfK2Y77Grxoc4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TUciysoXd5GZMQTL//5khKihjIPeGbRSiJkeJIhbPuGa2JuQcWCv/NxZRsSouk3QG x7oPrOde8NkEt9XeMpgcd90Four0C2NcmyO5B82czLW88C9g02tkncBl70tk+SHlfh 4bYzCO2g6OL6x4RTdaJCEAXZEAT45p7bhjuOwdVUMCfGUTJ+p3hCkE7qVovsBw+YO6 15Kv4oixA46GBcxtce7Qd8pexe1hP5BchsdWseZhcNjH2kZxv4ruiWWTdX7/zlWEeQ 1SGwvugAJTf3sYrf8C+x2O17XdJYv4/JRT/ICQvMF3bei7KrMquZs2tK4Soccn/t7a FVaTF7FAn/3Xw== Date: Tue, 14 Dec 2021 14:01:04 +0100 From: Marek =?UTF-8?B?QmVow7pu?= To: Stefan Roese Cc: Pali =?UTF-8?B?Um9ow6Fy?= , u-boot@lists.denx.de, Marek =?UTF-8?B?QmVow7pu?= Subject: Re: [PATCH u-boot-marvell v2 8/9] arm: mvebu: spl: Use IS_ENABLED() instead of #ifdef where possible Message-ID: <20211214140104.7a410847@thinkpad> In-Reply-To: <6cf901fd-01d7-6461-18e4-b362a37bac7c@denx.de> References: <20211126143738.23830-1-kabel@kernel.org> <20211126143738.23830-9-kabel@kernel.org> <20211214093600.e2sy5yrtpz7gvfna@pali> <20211214104515.2ae03d0d@thinkpad> <20211214111234.ie54zex6veoirfam@pali> <20211214134536.2baeb2a0@thinkpad> <6cf901fd-01d7-6461-18e4-b362a37bac7c@denx.de> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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.2 at phobos.denx.de X-Virus-Status: Clean On Tue, 14 Dec 2021 13:48:31 +0100 Stefan Roese wrote: > On 12/14/21 13:45, Marek Beh=C3=BAn wrote: > > On Tue, 14 Dec 2021 12:12:34 +0100 > > Pali Roh=C3=A1r wrote: > > =20 > >> On Tuesday 14 December 2021 10:45:15 Marek Beh=C3=BAn wrote: =20 > >>> On Tue, 14 Dec 2021 10:36:00 +0100 > >>> Pali Roh=C3=A1r wrote: > >>> =20 > >>>> On Friday 26 November 2021 15:37:37 Marek Beh=C3=BAn wrote: =20 > >>>>> @@ -340,17 +333,17 @@ void board_init_f(ulong dummy) > >>>>> timer_init(); > >>>>> =20 > >>>>> /* Armada 375 does not support SerDes and DDR3 init yet */ > >>>>> -#if !defined(CONFIG_ARMADA_375) > >>>>> - /* First init the serdes PHY's */ > >>>>> - serdes_phy_config(); > >>>>> - > >>>>> - /* Setup DDR */ > >>>>> - ret =3D ddr3_init(); > >>>>> - if (ret) { > >>>>> - debug("ddr3_init() failed: %d\n", ret); > >>>>> - hang(); > >>>>> + if (!IS_ENABLED(CONFIG_ARMADA_375)) { > >>>>> + /* First init the serdes PHY's */ > >>>>> + serdes_phy_config(); > >>>>> + > >>>>> + /* Setup DDR */ > >>>>> + ret =3D ddr3_init(); > >>>>> + if (ret) { > >>>>> + debug("ddr3_init() failed: %d\n", ret); > >>>>> + hang(); > >>>>> + } > >>>>> } > >>>>> -#endif =20 > >>>> > >>>> As written in comment above there is no SerDes and DDR3 support for > >>>> Armada 375 and therefore there is no serdes_phy_config() or ddr3_ini= t() > >>>> function. So this code needs not to be compiled at all and usage of > >>>> #ifdef is correct here. =20 > >>> > >>> #ifdefs are almost never correct in C-files, for the parts of the code > >>> they guard isn't put through syntactic analysis, and can therefore > >>> contain bugs which we are not warned about. > >>> > >>> Using if (IS_ENABLED()) almost never producess a different binary, > >>> because the code is optimized away. > >>> > >>> Marek =20 > >> > >> There is no function serdes_phy_config() for Armada 375, so if you put > >> it outside of #ifdef you will get compile error. =20 > >=20 > > The function is always declared in > > arch/arm/mach-mvebu/include/mach/cpu.h > > regardless of architecture. > >=20 > > Thus an error will be raised only when linking, and the compliation was > > done with -O0, which I don't think anyone does. > >=20 > > Anyway, if we want to support -O0, this can and should be solved via > > defining serdes_phy_config() as empty static inline function in the > > cpu.h header, guarded by #ifdef. In header files #ifdefs are allowed, > > in this manner: > > #if X > > declare function > > #else > > define that function as empty static inline > > #endif > >=20 > > So if you think we should support -O0, I can do this. > >=20 > > But the #ifdefs should really go away from real C code, that is the way > > both Linux and U-Boot are trying to go for the last couple of years, if > > I understand it correctly. =20 >=20 > Yes, the #ifdef's really should be avoided if possible. So *if* your > patch above does not generate any build issues, then I don't see any > problems to include it. I personally don't think that we need to support > -O0 builds. db-88f6720_defconfig builds without issue (armada 375). And it builds the relevant file, spl/arch/arm/mach-mvebu/spl.o. Marek