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 X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EC25C4338F for ; Wed, 11 Aug 2021 15:40:45 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id ABA4A60E09 for ; Wed, 11 Aug 2021 15:40:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org ABA4A60E09 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6BC8E82D2D; Wed, 11 Aug 2021 17:40:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (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="e5Cn5dtz"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 90A5C82D2D; Wed, 11 Aug 2021 17:40:40 +0200 (CEST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 8EC7480C85 for ; Wed, 11 Aug 2021 17:40:35 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x72d.google.com with SMTP id w197so2855112qkb.1 for ; Wed, 11 Aug 2021 08:40:35 -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:user-agent; bh=l0pzZHErb6rEWUVE48dV9k3ETb7KI17qZKQKHXKhrAQ=; b=e5Cn5dtzSi+2riHmUyAV84PF4c5e2NkHonjtkVZSVmzgHAbHCeKbZdx9jGbe3q0DEg EamrncX4oqN8+QyugMBm6KVJYVwOPNvGbxO9ibuM6uU+aPNNlsLEX5ookEgtdTobXwni UTW/hZja1ah0ivltjgGG7AzqkPUxnrRa3pNfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=l0pzZHErb6rEWUVE48dV9k3ETb7KI17qZKQKHXKhrAQ=; b=r/YSXoUcZj3xcYvSBVxig2yEBTWuT4l1UK3JApknA4YLZq7WK4WaLgsfSJ0ZFMXmyH a0pSIu2+DespY38TQ9DTcw59N6BTX5vNTOi7guqgh6GODkeNiYkmkZ/dJgqu8AYfqTX2 ruatV7mmNYb33oLZMsPn2pw0eKOKWjUaJ2AG6W68Ef72sm3pPibzsDXUfAkYnRIxqq9E Mm1i0KaHypNZ/N5ewDwT8/7mzeLKuYfK7ZCgXhbw6lnih9dUpHZppS6DsWqns16gOCJZ 6HOs9CzUZJNL3Z1kETd6vaKymDjs5JjG0UVDD1d1ngPhdOLpSNd8eZK8nXOn4zLOdXQ7 X+GQ== X-Gm-Message-State: AOAM532rnJuYe8PgU0Lnk4M1y1qR6yRavEwzQuNTl73X01DcJHAc14ce P6Pi2wFn5aCuNDImX2R18f9O/w== X-Google-Smtp-Source: ABdhPJzRFnD1HrgJSiiji9iEFWeu+NK/HzM07FpJLvMVTHTL/eY8J5sZeq8/nssgzpl7tY7r/mYh4Q== X-Received: by 2002:a05:620a:129c:: with SMTP id w28mr206562qki.132.1628696434156; Wed, 11 Aug 2021 08:40:34 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-ddfe-3f7e-6e5c-2811.res6.spectrum.com. [2603:6081:7b01:cbda:ddfe:3f7e:6e5c:2811]) by smtp.gmail.com with ESMTPSA id j127sm12758175qkf.20.2021.08.11.08.40.32 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Aug 2021 08:40:33 -0700 (PDT) Date: Wed, 11 Aug 2021 11:40:30 -0400 From: Tom Rini To: Simon Glass Cc: U-Boot Mailing List , Marek Vasut , Masahiro Yamada , Heinrich Schuchardt , Bin Meng , Stefan Roese , Marek =?iso-8859-1?Q?Beh=FAn?= , Sean Anderson , Aaron Williams Subject: Re: RFC: Support for U-Boot phases in Kconfig Message-ID: <20210811154030.GD858@bill-the-cat> References: <20210809191111.GD858@bill-the-cat> <20210810193809.GL858@bill-the-cat> <20210811134732.GV858@bill-the-cat> <20210811141706.GY858@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4qaNdQPTTtjqwN2H" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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 --4qaNdQPTTtjqwN2H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 11, 2021 at 08:26:38AM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Wed, 11 Aug 2021 at 08:17, Tom Rini wrote: > > > > On Wed, Aug 11, 2021 at 08:03:00AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 11 Aug 2021 at 07:47, Tom Rini wrote: > > > > > > > > On Wed, Aug 11, 2021 at 06:56:31AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Tue, 10 Aug 2021 at 13:38, Tom Rini wrote: > > > > [snip] > > > > > > I need to take another pass at converting a bunch of symbols, t= o see > > > > > > where we're at. Probably the biggest chunk of progress next wo= uld be to > > > > > > start converting CONFIG_SYS_xxx to SYS_xxx and moving defines o= ut of > > > > > > config.h and in to something else. I'm taking a peek at some o= f the > > > > > > remaining PCI ones now. > > > > > > > > > > How about we set a deadline for this? It has gone on for too long= and > > > > > we just need to drop these CONFIGs. It's probably a higher priori= ty > > > > > than a Kconfig change. > > > > > > > > > > I was expecting that the config.h files would go away and we woul= d use > > > > > Kconfig (or DT) for everything. What sort of things don't fit into > > > > > that model? > > > > > > > > Environment is the hard one to move out from config.h and in to, we= ll, I > > > > > > Well you know my views on that :-) > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git= -send-email-sjg@chromium.org/ > > > > > > I still think it makes more sense than #defines and I can resurrect > > > that series if you like. > > > > That might work, yeah. I just also want to focus on less things in > > progress at once. That too I think has been part of why everything is > > taking so long. >=20 > OK I'll take a look. Other things in progress I can think of are: >=20 > - drop common.h (could be done in one series if we just go for it) > - set up issue tracking so we can keep an eye on these things Well, all of the DM migrations that have deadlines, and the there's probably some that don't still. And the high level size concern about using DM on platforms where dynamic selection/detection isn't a functional win. > > > > don't know what. I think there's also a handful of symbols like > > > > CONFIG_SPL_MAX_SIZE that are a little tricky to convert directly (t= hey > > > > do math based on other symbols) rather than just as evaluate-and-se= t. > > > > > > We can either evaluate them and put the answer in as the defconfig > > > value...or perhaps ask Masahiro to support evaluation in kconfig?! > > > > I do forget what kind of operations are allowed in Kconfig at this > > point, it might be possible now, yes. And if not, something worth > > trying. >=20 > OK >=20 > > > > > > Right now, a little more than half of the unmigrated symbols are > > > > CONFIG_SYS_xxx things and those likely should become SYS_xxx things= =2E Of > > > > the ones that don't just go away. > > > > > > Do you mean things like this? > > > > > > arch/m68k/include/asm/immap.h:#define CONFIG_SYS_PCI_BAR0 > > > (0x40000000) > > > > > > Assuming this doesn't move to devicetree, it should be in its own asm/ > > > or asm/arch header file I think, not in the config.h file at all. > > > > > > FSL layerscape should move CONFIG_SYS_PCIE3_PHYS_SIZE et al to devcet= ree. > > > > I started and set aside *PCI* since a bunch of that goes away once > > UCP1020 gets updated. But yes, there are lots of CONFIG_SYS_xxx things > > that live inside and outside of config.h and step one is likely a simple > > regex. They aren't really configurable. We can try and figure out what > > "get this from DT" approach makes sense after. >=20 > Yes agree we can't wait for DT move. >=20 > > > > > Some of the DM migrations will help - e.g. for I2C. NAND seems to have > > > a lot - who is the NAND maintainer? > > > > There's not currently a NAND maintainer. > > > > > But really what I am asking is, can we set a deadline where all > > > config.h files will be dropped? It has been 7 years... > > > > It's going to come down once again to figuring out what to do about > > older platforms. Since I picked on khadas platforms earlier, here's > > where meson64.h looks really good. All of the platforms use > > include/configs/meson64.h and that's very little outside of environment > > stuff. To go back to another part of the thread, it also shows how hard > > environment stuff is. >=20 > Well let's see. >=20 > > > > It also reminded me that buildman never got kconfiglib support directly > > and we still have genboardcfg.py to spit out boards.cfg to be parsed by > > buildman. >=20 > Ah yes, so is buildman the only reason we have that file? I do like > being able to grep it for stuff, but I suppose buildman could support > that. Is there no other user? Ah, yes, so there's two things it does. One is buildman. Two is "spit an error out if a defconfig lacks a MAINTAINER entry". The latter is important but could be its own tool, and then of course looking at MAINTAINER files is how to see what config header a given defconfig uses. --=20 Tom --4qaNdQPTTtjqwN2H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmET72UACgkQFHw5/5Y0 tyyoUgwAlqpAWSkZiRv6Y8pjdt8ci9b+cTzi28cpKXPntlJq/CKGw8Rm2ar0UcRI UxslDHzOI+wogW0uUAe7Pp2XHqSvXGKad/uOJhh5aynbb+1LUrqWE4nnU/GApyPa 0FLxF0LEkp/m02DwlYg0qqS1DRdqeyf9emvlMVfyB5wG6HMcqxu8h2FtiAH+gCqX wFF1tGPSZvbuctuSVYsO/LUTWoEyiOjo0IpXm9GG3zX5BH7pmfXjhnV+0yA1ujMx QZuLRiTwMbIDv728d768jbdJ//kPM6GrDthjUWJpH+MujZulzKaLBenm3N4qU18x Nu/i+2GpbN2fuD2ybSs/YIdEU8yWKOerfU4KpkOMR/D00lyx8k5N9CnEf8niihIV z3CAfgn2VYkmIybkFXyLwQgP/ahrAtK1UCs7InWta1bEYLT7GC4JUptUhPtng/kF aXQ/oKxBXGN1drOVuxu2T+KfGpUc3UrY+VrhC+Tjhvp+P7v3ZpiSjHFY5sonNbuD 1EVvt0gm =CYBe -----END PGP SIGNATURE----- --4qaNdQPTTtjqwN2H--