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 48956C433EF for ; Thu, 12 May 2022 16:01:38 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 43CDD833EC; Thu, 12 May 2022 18:01:36 +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="L418682m"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DA97A83D4B; Thu, 12 May 2022 18:01:34 +0200 (CEST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 44A4A80584 for ; Thu, 12 May 2022 18:01:31 +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-x82a.google.com with SMTP id p4so4754606qtq.12 for ; Thu, 12 May 2022 09:01:31 -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=YE0Hp0bVzQf6Uny0blx6Px/F+P+y1ZWUiLUFb5qTNl0=; b=L418682mikItG7c7Xf+rC9ZjlUgRA7nv3qExV/KJUCAHfqJtculTZkbrT992D7XTy3 GryXZw4EY5sMu6E6qYUqhyGn+p8OCNq47n2RtvQ/+WXxzPDbCFyJuX7lu0Bk3JPM1uS6 BtW67JqlOf688gjyY1ieY4yneqCRfA6Wzovhc= 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=YE0Hp0bVzQf6Uny0blx6Px/F+P+y1ZWUiLUFb5qTNl0=; b=29y1DbN2+V3l3tBXC7QNMR9NwU+8CeHM+j8vXSRNxl443+3WXd9DKxjz8U4eXPmUh3 FJ3p70Vi3kXPiazmzToLn7yw2zY/fbnkT/1WxvAmJx7icsf6HuSIgvhjh7ikPEjJOXEZ DnB1kg5ArnIsnZlFQvIH8ezMdYkPQK8At9kVfJL7c6GP5PjLJREnCak60X9meYr7hT++ yaQq3yVwpuooHUr2g5d73kv4K3lIIpRTqk3gW/D/vOjFQ56tllgfFevLP53qcz6uotyZ J1dqx7wiBanj/n3Sv0GjsQ/Eb13qJ5QUIfwXO//JtgKV2A81sbr+M2YtexLaWywTXSFH jpJw== X-Gm-Message-State: AOAM531HFiuZ8Fmim7jvL4hKSya+fTbkfVz1jhFcPYWULSpdhkkiA1Oi 4cDMWem/h7DIBghMmaNqXWe5Rw== X-Google-Smtp-Source: ABdhPJzftujrBK3A3ZzXa2tL85oTiQpeB9P7rqTgSJNIa0dMHgQGF0V/VV0DxMBt1hiyDKrRE2Ah/w== X-Received: by 2002:ac8:7f8d:0:b0:2f3:ec97:f95 with SMTP id z13-20020ac87f8d000000b002f3ec970f95mr401059qtj.273.1652371289680; Thu, 12 May 2022 09:01:29 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-4500-88f1-df08-fb5b-7a50.res6.spectrum.com. [2603:6081:7b01:4500:88f1:df08:fb5b:7a50]) by smtp.gmail.com with ESMTPSA id f18-20020ac84712000000b002f39b99f6bbsm3242261qtp.85.2022.05.12.09.01.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 May 2022 09:01:28 -0700 (PDT) Date: Thu, 12 May 2022 12:01:26 -0400 From: Tom Rini To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: u-boot@lists.denx.de Subject: Re: [PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig" Message-ID: <20220512160126.GD3901321@bill-the-cat> References: <20220501142357.16778-1-pali@kernel.org> <20220501142357.16778-2-pali@kernel.org> <20220501143939.GH1182808@bill-the-cat> <20220501144416.hpnnsoulsz6h3ztt@pali> <20220501151421.GI1182808@bill-the-cat> <20220501153319.l7ab6skdwgbnv4b4@pali> <20220501161751.GJ1182808@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oTjmB4SGUHx7SKxS" Content-Disposition: inline In-Reply-To: <20220501161751.GJ1182808@bill-the-cat> 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 --oTjmB4SGUHx7SKxS Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 01, 2022 at 12:17:51PM -0400, Tom Rini wrote: > On Sun, May 01, 2022 at 05:33:19PM +0200, Pali Roh=E1r wrote: > > On Sunday 01 May 2022 11:14:21 Tom Rini wrote: > > > On Sun, May 01, 2022 at 04:44:16PM +0200, Pali Roh=E1r wrote: > > > > On Sunday 01 May 2022 10:39:39 Tom Rini wrote: > > > > > On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Roh=E1r wrote: > > > > >=20 > > > > > > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1. > > > > > >=20 > > > > > > This commit made configuration, understanding, maintenance, deb= ugging and > > > > > > future development of the powerpc/mpc85xx Local Bus Controller = on P1/P2 > > > > > > boards impossible. > > > > > >=20 > > > > > > All preliminary Base and Option registers depends on other code= and C > > > > > > macros generated at C compile time and they comes from the othe= r macros. > > > > > >=20 > > > > > > For example, NOR base address and NOR options are set via macros > > > > > > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And = then based > > > > > > on other logic are filled correct values in to the correct macr= os > > > > > > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM. > > > > > >=20 > > > > > > These config options are not user configurable options and ther= efore > > > > > > should not appear in menuconfig. Moreover for P1/P2 boards they= have > > > > > > nothing with DDR driver, so they should not appear in drivers/d= dr. > > > > > >=20 > > > > > > This change was completely wrong direction, so revert it. It al= lows to > > > > > > start fixing issues with FLASH, NOR, NAND and CPLD LBC configur= ation. > > > > > > In current state it is impossible. > > > > > >=20 > > > > > > See also thread for more details: > > > > > > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@= pali/t/#u > > > > > >=20 > > > > > > Signed-off-by: Pali Roh=E1r > > > > >=20 > > > > > NAK. We are not moving things back in to board config headers un= der > > > > > CONFIG namespace. Some other solution is required. > > > >=20 > > > > I spend time on this and I do not see any other solution. As explai= ned > > > > that commit just introduced more issues then what it brought, so it= was > > > > step backward, not forward. So please show other solution, if you d= o not > > > > like this one. > > >=20 > > > Anything that I suggested in the previous thread about moving to board > > > Kconfig files. > >=20 > > Kconfig does not support evaluating C macros from C header files. So it > > would not work. >=20 > Document how to derive them using tools like 'printf' when adding more > boards, which should not be a common case anyhow. >=20 > > > Or move it to some other header and out of CONFIG namespace. > >=20 > > This is board specific setting, used by drivers and arch code. So it > > needs to be in some board location, like the config header file. >=20 > But all include/config/*.h files are destined to be removed, so they > cannot live there. Everything in the CONFIG namespace needs to be in > Kconfig. Nothing outside of CONFIG namespace belongs under > include/configs/. >=20 > > > Or if dtoc (doc/develop/driver-model/of-plat.rst) isn't > > > sufficient today to pull out the infos to use at build time, expand it > > > to cover this case as it would be useful for large numbers of other > > > cases. > >=20 > > This would mean to rewrite completely everything about LBC configuration > > and its peripherals. I really do not have energy nor time for it. >=20 > Neither apparently has anyone else for the last far far too long. >=20 > > There are issues which needs to be fixed first, then some "code cleanup" > > and "non-functional" changes could be done. > >=20 > > But that your commit c7fad78ec0ee41b72a58bebb61959570eb937ab1 make it > > impossible to do anything with LBC, neither new development, nor doing > > bug fixes. So it is in the worst state in which it can be. >=20 > How? Derive the correct hex value and put it in. >=20 > > That commit has same effect as conservation of the code and putting it > > into the state to disallow future development in this area. Because > > everybody who wants to touch it, has to first do what you wrote above. >=20 > Yes. The code is sub-standard and needs improvement. >=20 > > But this is such giant work which nobody is going to do, just for fixing > > small bug, which is completely unrelated to that work. And that work is > > only refactor/code cleanup which does not bring any functional value. > > Nothing so fancy, that somebody would do in spare time. > >=20 > > So I hope that this was not your intension. >=20 > My intention is to get the PowerPC code up to modern U-Boot standards. > Or, to get it removed since there's not enough interest in maintaining > and updating it. >=20 > To re-iterate, I agree that it would be good to construct the values at > build time using macros. No one likes looking at raw magic values. But > for an otherwise dead end platform, documenting how these magic values > are constructed (something under doc/arch/ or doc/board/) for anyone in > the future doing more work is Good Enough for me. Alternatively, > re-working things so that instead of being pulled from > include/configs/board-config.h they come from board/.../something.h is > Good Enough, so long as they are NOT using the CONFIG prefix. They can > use CFG_ or just LBC_ or anything else that makes sense. Getting back to this. I see 13 more "LBC" CONFIG symbols that need something done to them. I'm sure most or all of them are in the same situation as the PRELIM ones in this thread. Have you attempted to move them out of the CONFIG namespace by chance? If not, I might start looking soon at where to move them to, rather than migrate to Kconfig. Thanks. --=20 Tom --oTjmB4SGUHx7SKxS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmJ9L08ACgkQFHw5/5Y0 tyyZRAv9FGS58v07cmK5nxM7QxL47VSQU9hFXDcBCuqBukk5CHj6/hGs9133lQCt AQG2Beor21cMjbZEeYyFmLTbl2cU8k5msdlo6oTanoZMHMdO/LD6CF17jSVOwJYm CP7WUtFBWfpYsL3s9xBwPyuk/2Mg3/E3WnfmtNeqPejw9m6+dZ8lWU4xyaGZyjiV EqadgtUIHXyDhPkOCNLR7/D3ZGMd5+8UvqUsCY3wNzeY8zdvZXavhDg+dIy8jqgy l9uYf1UKf1q5Iy0ipEHKW4NcH8O1ilWK61t7l5c5cVOgbU53m/m2C6YsJq5QHYCz 5MvzETVY8rImVUvibFo5n/1RZyeoYJQoE8YedL3iEd4GR3EpKiJ3qTjq2BdqTFDB 2x5j7y7Mf0mm5/nmqN+s28CSq0kvco3x3/PYSrF9H7DNjFg41RDyNmO3h5woeQqv AS0V8ew0y8MajDnreBL3LmOKSHkhPibZmepw0VNueTI+fWd1SQQRRnX/9lQlu5CK wbqf6F// =GpLt -----END PGP SIGNATURE----- --oTjmB4SGUHx7SKxS--