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 A9980CCA481 for ; Mon, 18 Jul 2022 20:03:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1C9BD83E13; Mon, 18 Jul 2022 22:03:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id EFCB283E92; Mon, 18 Jul 2022 22:02:58 +0200 (CEST) Received: from mx1.tinet.cat (mx1.tinet.org [195.77.216.146]) (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 7F7CE83C35 for ; Mon, 18 Jul 2022 22:02:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xdrudis@tinet.cat X-ASG-Debug-ID: 1658174574-163e7b70c4799290001-4l7tJC Received: from smtp01.tinet.cat (smtp01.tinet.cat [195.77.216.131]) by mx1.tinet.cat with ESMTP id U8VgXeX1qbNPUcYq; Mon, 18 Jul 2022 22:02:54 +0200 (CEST) X-Barracuda-Envelope-From: xdrudis@tinet.cat X-Barracuda-Effective-Source-IP: smtp01.tinet.cat[195.77.216.131] X-Barracuda-Apparent-Source-IP: 195.77.216.131 Received: from begut (99.red-79-152-185.dynamicip.rima-tde.net [79.152.185.99]) by smtp01.tinet.cat (Postfix) with ESMTPSA id 9E787605D0A1; Mon, 18 Jul 2022 22:02:54 +0200 (CEST) Date: Mon, 18 Jul 2022 22:02:53 +0200 From: Xavier Drudis Ferran To: Quentin Schulz Cc: sjg@chromium.org, philipp.tomsich@vrull.eu, kever.yang@rock-chips.com, alpernebiyasak@gmail.com, email2tema@gmail.com, jagan@amarulasolutions.com, u-boot@lists.denx.de, Quentin Schulz Subject: Re: [SPAM] [PATCH v2 2/2] rockchip: rk3399: fix incorrect ifdef check on SPL_GPIO Message-ID: <20220718200252.GE1686@begut> X-ASG-Orig-Subj: Re: [SPAM] [PATCH v2 2/2] rockchip: rk3399: fix incorrect ifdef check on SPL_GPIO References: <20220715150949.952853-1-foss+uboot@0leil.net> <20220715150949.952853-2-foss+uboot@0leil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220715150949.952853-2-foss+uboot@0leil.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Barracuda-Connect: smtp01.tinet.cat[195.77.216.131] X-Barracuda-Start-Time: 1658174574 X-Barracuda-URL: https://webmail.tinet.cat:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 4493 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: SPAM GLOBAL 0.9962 1.0000 4.2985 X-Barracuda-Spam-Score: 4.30 X-Barracuda-Spam-Status: No, SCORE=4.30 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=6.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.99470 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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 El Fri, Jul 15, 2022 at 05:09:49PM +0200, Quentin Schulz deia: > From: Quentin Schulz > > The check to perform is on CONFIG_SPL_GPIO and not SPL_GPIO. > Because this was never compiled in, it missed an include of cru.h that > was not detected before. Let's include it too. > > Also switch to IS_ENABLED ifdef and in-code check. > > Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init") > Cc: Quentin Schulz > Signed-off-by: Quentin Schulz > --- > I've tested this on a Rock-Pi-4B, but with the patch below on top and I haven't seen any regression. So, with this small correction: Tested-by: Xavier Drudis Ferran > v2: > - use IS_ENABLED checks, > > arch/arm/mach-rockchip/rk3399/rk3399.c | 45 ++++++++++++++------------ > 1 file changed, 24 insertions(+), 21 deletions(-) > > diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c > index 920da22307..db8a6cb83a 100644 > --- a/arch/arm/mach-rockchip/rk3399/rk3399.c > +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c > @@ -221,7 +221,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) > "u-boot,spl-boot-device", boot_ofpath); > } > > -#if defined(SPL_GPIO) > +#if IS_ENABLED(CONFIG_SPL_GPIO) > + > +#include > static void rk3399_force_power_on_reset(void) > { > ofnode node; > @@ -253,27 +255,28 @@ void spl_board_init(void) > { > led_setup(); > > -#if defined(SPL_GPIO) > - struct rockchip_cru *cru = rockchip_get_cru(); > + if (IS_ENABLED(CONFIG_SPL_GPIO)) { > + struct rockchip_cru *cru = rockchip_get_cru(); > > - /* > - * The RK3399 resets only 'almost all logic' (see also in the TRM > - * "3.9.4 Global software reset"), when issuing a software reset. > - * This may cause issues during boot-up for some configurations of > - * the application software stack. > - * > - * To work around this, we test whether the last reset reason was > - * a power-on reset and (if not) issue an overtemp-reset to reset > - * the entire module. > - * > - * While this was previously fixed by modifying the various places > - * that could generate a software reset (e.g. U-Boot's sysreset > - * driver, the ATF or Linux), we now have it here to ensure that > - * we no longer have to track this through the various components. > - */ > - if (cru->glb_rst_st != 0) > - rk3399_force_power_on_reset(); > -#endif > + /* > + * The RK3399 resets only 'almost all logic' (see also in the > + * TRM "3.9.4 Global software reset"), when issuing a software > + * reset. This may cause issues during boot-up for some > + * configurations of the application software stack. > + * > + * To work around this, we test whether the last reset reason > + * was a power-on reset and (if not) issue an overtemp-reset to > + * reset the entire module. > + * > + * While this was previously fixed by modifying the various > + * places that could generate a software reset (e.g. U-Boot's > + * sysreset driver, the ATF or Linux), we now have it here to > + * ensure that we no longer have to track this through the > + * various components. > + */ > + if (cru->glb_rst_st != 0) > + rk3399_force_power_on_reset(); > + } > > if (IS_ENABLED(CONFIG_SPL_DM_REGULATOR)) { > /* > -- > 2.36.1 > The small correction (now that I think of it, the include might as well go at the top of file): --- arch/arm/mach-rockchip/rk3399/rk3399.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index fced5c7e21..10b911f998 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -221,9 +221,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) "u-boot,spl-boot-device", boot_ofpath); } +#include #if IS_ENABLED(CONFIG_SPL_GPIO) -#include static void rk3399_force_power_on_reset(void) { ofnode node; @@ -245,6 +245,10 @@ static void rk3399_force_power_on_reset(void) dm_gpio_set_value(&sysreset_gpio, 1); } +#else +static inline void rk3399_force_power_on_reset(void) +{ +} #endif void __weak led_setup(void) -- 2.20.1