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 495EFC433F5 for ; Wed, 27 Apr 2022 13:09:35 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7749283AEB; Wed, 27 Apr 2022 15:09:32 +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="dlMhuSgM"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2DF4983D67; Wed, 27 Apr 2022 15:09:30 +0200 (CEST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 33F1C83AE6 for ; Wed, 27 Apr 2022 15:09:26 +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-qk1-x733.google.com with SMTP id 126so230564qkm.4 for ; Wed, 27 Apr 2022 06:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nNhfD7KMkhyQCrlOPsfXXW527LMaTCNHPsrvhubjRps=; b=dlMhuSgMQeA7koW4bmPKFMzJ3npy7HujELn7tgiMMVqVHtn+iNaf8zx9y2z4fT1Hcy pwMKg/LkW/Ulq0K3mNrcRuOQOM4yH0cFn/H0gTAVP8KLMjZb4y6J8VflFlQQA6P/Xt6W jyAd8bdZ3XPlMgKgwKnD5QYeWIWAo28+ki5+Y= 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:references :mime-version:content-disposition:in-reply-to; bh=nNhfD7KMkhyQCrlOPsfXXW527LMaTCNHPsrvhubjRps=; b=XlD3+VaEBEp5a0vVxjqhoKCOiLaf9IDMmfdHu6FKj1RReCVAz11ft68+nTyo8+84o0 R0FAmJLRMRpATglYMtHII0zeGkm/fMKYC1OeVBAjsSTiQO/Bo+VDzr+6MUk6p7XajABX j2dGc2Btm8/AzGCF1I1wMPQFeOaH0RtWzKHIkkyAM79bdZA9j42edTh95Yk0bipgZc4K I5iEQ0qqr7PtuZluCl3cph/Xs56Sd4k+Ot8P8kSltdUec/cobXX/yCzdXzC/nQ0lJlIL 6sUEPSF8ptEgi8Js7qZeTScYQRk17OaiTXoOH5F7hMRE+OndQDrG4wPi/s9B/UCT8LuA aUhg== X-Gm-Message-State: AOAM533ZGGA8PPW0FqAyHAjoMNTMei6Tx2tTYqBg8HeBwyEz2HNdFtLl yJ98ZhAWziqcqsdE9p77TMKd3g== X-Google-Smtp-Source: ABdhPJz2sr6RrtN3+37GxSEd/F44UQmPHrD4GnA169c66wXAjN+i2FkyXDVhbayEN3iP2vtJ9VL7ig== X-Received: by 2002:a37:9a83:0:b0:67b:31be:2ac2 with SMTP id c125-20020a379a83000000b0067b31be2ac2mr16280420qke.416.1651064964852; Wed, 27 Apr 2022 06:09:24 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-4d8f-c477-6f29-9e62.res6.spectrum.com. [2603:6081:7b01:cbda:4d8f:c477:6f29:9e62]) by smtp.gmail.com with ESMTPSA id b126-20020a37b284000000b0069a11927e57sm7940934qkf.101.2022.04.27.06.09.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 06:09:24 -0700 (PDT) Date: Wed, 27 Apr 2022 09:09:21 -0400 From: Tom Rini To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Priyanka Jain , Sinan Akman , u-boot@lists.denx.de Subject: Re: Suggestion: Revert commit c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig") Message-ID: <20220427130921.GH7271@bill-the-cat> References: <20220426181740.o2n7xfg46ytljcdx@pali> <20220426182348.GD7271@bill-the-cat> <20220426183526.2wf3buag5pv2rilf@pali> <20220426184740.GE7271@bill-the-cat> <20220426190744.qfmh2wblbebzlgpj@pali> <20220426194042.GF7271@bill-the-cat> <20220427072052.7yv4qiufhggvb7dg@pali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xHbokkKX1kTiQeDC" Content-Disposition: inline In-Reply-To: <20220427072052.7yv4qiufhggvb7dg@pali> 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 --xHbokkKX1kTiQeDC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2022 at 09:20:52AM +0200, Pali Roh=E1r wrote: > On Tuesday 26 April 2022 15:40:42 Tom Rini wrote: > > On Tue, Apr 26, 2022 at 09:07:44PM +0200, Pali Roh=E1r wrote: > > > On Tuesday 26 April 2022 14:47:40 Tom Rini wrote: > > > > On Tue, Apr 26, 2022 at 08:35:26PM +0200, Pali Roh=E1r wrote: > > > > > On Tuesday 26 April 2022 14:23:48 Tom Rini wrote: > > > > > > On Tue, Apr 26, 2022 at 08:17:40PM +0200, Pali Roh=E1r wrote: > > > > > >=20 > > > > > > > Hello! I would suggest to revert commit c7fad78ec0ee ("Convert > > > > > > > CONFIG_SYS_BR0_PRELIM et al to Kconfig"). > > > > > > >=20 > > > > > > > The reason is that this commit made configuration, understand= ing, > > > > > > > maintenance and debugging of the powerpc/mpc85xx Local Bus Co= ntroller > > > > > > > hard, mainly impossible. > > > > > > >=20 > > > > > > > This commit completely removed usage of named macros, to easi= ly check > > > > > > > address and size of the LBC memory banks. Removal was done al= so for > > > > > > > explaining comments of configuration options. > > > > > > >=20 > > > > > > > It is just a mess what this commit introduced and took me rea= lly long > > > > > > > time to debug and understand what is happening here... until = I reverted > > > > > > > this commit manually in my tree. > > > > > > >=20 > > > > > > > Any opinions? > > > > > > >=20 > > > > > > > Btw, current values are wrong. > > > > > >=20 > > > > > > AFAICT, the current values match what was in use prior. > > > > >=20 > > > > > I'm not going to verify that these values really match as playing= with > > > > > those magic numbers is a pain. > > > >=20 > > > > Right. It's been a while since I linked it, but: > > > > https://patchwork.ozlabs.org/project/uboot/patch/1500407318-7977-1-= git-send-email-trini@konsulko.com/ > > > > is what I use for migrating non-obvious values to Kconfig. So I us= ed > > > > that to print out all of these, I'm pretty sure before and after. > > >=20 > > > Ok. I guess that this should generate same values for _default_ > > > configuration. But modification via menu config does not have to prod= uce > > > correct values... > > >=20 > > > > > But some of these values were wrong even before that commit. And = this > > > > > can be verified easier (just checking that size does not match to > > > > > expected value in DTS or documentation). > > > >=20 > > > > So some bitrot, probably then, sigh. > > >=20 > > > The point is that now with magic hex values, it is impossible to dete= ct > > > that constants are not correct. > > >=20 > > > Previously when constants were defined via named macros, it was lot of > > > easier. > > >=20 > > > So, if I see that previously Option Register for NAND bank was > > > initialized to value > > >=20 > > > (OR_AM_32KB | OR_FCM_PGS | OR_FCM_CSCT | OR_FCM_CST | OR_FCM_CHT | = OR_FCM_SCY_1 | OR_FCM_TRLX | OR_FCM_EHTR) > > >=20 > > > I could easily detect that this values is incorrect for NANDs with la= rge > > > paging, which needs 256 kB window. > > >=20 > > > But now if I see just magic value 0xFFFF8396 I do not spot that this > > > value encodes 32 kB instead of 256 kB. > > >=20 > > > This is the way how to hide issues and possible bugs. > > >=20 > > > > > > But, these should probably not be in CONFIG namespace at all > > > > >=20 > > > > > Well, they do not belong to defconfig. These values are not user > > > > > configurable and are board wiring dependent. So should have never > > > > > appeared in menu config. > > > >=20 > > > > So they shouldn't be asked and should be: > > > > config SYS_FOO > > > > hex > > > > default 0xBEEF > > > >=20 > > > > in the board Kconfig files. And the help part of > > > > drivers/ddr/fsl/Kconfig updated to explain where/how to figure out = or > > > > find the appropriate values. > > >=20 > > > Having value in board Kconfig file _without_ help text (to make config > > > option _not_ user selectable) is a little bit better. But it lacks he= lp > > > text and still does not solve the problem with magic constants which > > > just hide issues. > >=20 > > So, part of the problem is that you shouldn't do what we do today of > > duplicating "config FOO" in multiple places. Copy/pasting that help > > probably won't break things, but isn't I think an improvement. There's > > lots of cases where I suggest / just tell people to have: > > config FOO > > hex > > default 0x100 if A > > default 0x200 if B || C > > and so on, and that's also not ideal, but I think does help lead to > > consolidation down the line. That won't be the case here, since these > > are board-specific and I can see objections to default 0xBEEF if > > TARGET_BAR and so on. And as you note above, these should be > > constructed in many / most cases. > >=20 > > > For this one particular case for *PRELIM* macros, I'm thinking if it > > > would not be better idea to move all these constants into global > > > variables / arrays, defined in board source files. Like are already > > > defined configuration to TLB entries or LAWs. See files: > > > board/freescale/p1_p2_rdb_pc/law.c > > > board/freescale/p1_p2_rdb_pc/tlb.c > > > Code which needs these values just access (global) variable/array, see > > > how those files are used. > >=20 > > I agree that what's there now isn't ideal. But "leave things in the > > board.h files until someone can do a clever conversion for these harder > > problems" hasn't worked. I am quite open to moving forward with better > > suggestions, especially since there's quite likely more cases of magic > > values needing to be moved out of where they are and not being really > > user-configurable either. >=20 > In any case, if I'm looking at these PRELIM macros correctly, they are > not DDR-related, so I do not understand why they are defined in > drivers/ddr subtree. They are purely LBC specific and required for > correct preliminary access to local bus, specially NAND or NOR. Some value I was checking on, I think, was referenced under there, so that's where I put it. Moving it all elsewhere the makes more sense is also totally fine and appropriate. --=20 Tom --xHbokkKX1kTiQeDC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmJpQHgACgkQFHw5/5Y0 tyzCRQv+Jl1khoJ5XLpf0IIZiC706vyBUDPfDL4CrbESym+kFwNjjo7Xe6+EocZp FvZGu6HMMNHFO2TUmonLOCP3XgzSUOQmsGnWBdmzEeOYyvVlnXQxOjmS7vOv968n xOvUZfLRl679So/s6t8nbGtUw5ySQmFvsaciYPkF6sAdLUEapAu5ZI+TxCgwlSZz uEM2LKVh9m7cevf0ulH75MDK03lFovwr6Ku0DCPHStK1RbL5bNsBXrwrf7Qvv1s4 R5tsfjodnqZN+DUV+KbuT1mt1mVYTh6PlESumKj1DXgGyJz0nsMOpPB3GY+hK1/i 7yWcqA3I0/uVqxDUekoEpOQfoDahHUgvQT/jQHNelLmmkbGCQxvmM7KKl98szTuz evoytHBi/bu3yoTI76aUPyk4vnmIW/87LG7mNZc/LMbweM2f0WVHE44Q8Mg700Cz Lh3TJKbKaLVVqeqjrpfYN+vjUX0QkJUYy8Jkcwdnnzgq8jWSQAk3ogNZadqSoVhb yhuauSmp =8CRh -----END PGP SIGNATURE----- --xHbokkKX1kTiQeDC--