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 0D96DEB64DA for ; Sun, 16 Jul 2023 15:12:14 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E1F6086332; Sun, 16 Jul 2023 17:12:12 +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="kWZsLoeI"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8EB6086307; Sun, 16 Jul 2023 17:12:11 +0200 (CEST) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 D150D847D3 for ; Sun, 16 Jul 2023 17:12:08 +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-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-cabf1dbafc4so3742602276.2 for ; Sun, 16 Jul 2023 08:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; t=1689520327; x=1692112327; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0pET9xe0B1GvaZ9VvQGxSOV0RqTKX/ublRmEmhRalTk=; b=kWZsLoeINH3NeMxuAOW/ClvkVOvDw+6PGvLCN5T37BAn+7msZAm4SM16ZM/Efb3G1J dAyP/QqqjxPYMQntXA4I03LJe8QyGDa7lzOkoNDZaTiwL1o8HWYuPI9cf/Z88ZEKG7Xk WkFXAfs/pkBRI98qvXPCLfjfME7UHw9Ei7j6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689520327; x=1692112327; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0pET9xe0B1GvaZ9VvQGxSOV0RqTKX/ublRmEmhRalTk=; b=khRiR9lHQ0sa+44FzZofXR/kYHyVMvo144xJq0gJp4k31q5Y+DmBvJjxqdd4JQmeGu E+axZ/+p1b08A7yYSR8/MS+QN/V1haG2k2Is/InHembR/q1WR4wmr8qYa/UQcReOHrAN RuXEGD7wr1SeDTl6rHMaEyibGBsMTAb+Hak9JdF9z+PKK/Z8QJxD+KuJ7stvPyfDOIZu aw8Vj5VtgQTWeUcWPqDA1IPtp300DfHXEd6mGeNH6clcq9fqq9Gvx/bwlLVKXxySnFBV HELKob093xGqfoEVqZTraMyV1Qqhjpuarcn5CVEoOaGXjtK6fAlUMnQ1Yn2jTMtU5hn/ 9BEg== X-Gm-Message-State: ABy/qLZInSre+t2PwKmTEGEQ/JiLKQZTI1pjC96mwMWAurBUfL6VykTw jFu84BsgUGbU0tiId+lEiZfoDw== X-Google-Smtp-Source: APBJJlH7cdDSAX7R4CGxTPxshXH+eGoqJaNkNIVx5ynttsnLv2YA7IAHGjPPqnAivzSPVzNYGRFypA== X-Received: by 2002:a0d:ed83:0:b0:570:220:f815 with SMTP id w125-20020a0ded83000000b005700220f815mr10486309ywe.11.1689520327355; Sun, 16 Jul 2023 08:12:07 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b00-6400-5e84-cf0c-0c9a-a3e2.res6.spectrum.com. [2603:6081:7b00:6400:5e84:cf0c:c9a:a3e2]) by smtp.gmail.com with ESMTPSA id v123-20020a0dd381000000b00577269ba9e9sm3358445ywd.86.2023.07.16.08.12.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jul 2023 08:12:06 -0700 (PDT) Date: Sun, 16 Jul 2023 11:12:05 -0400 From: Tom Rini To: Simon Glass Cc: Jason Kacines , Andrew Davis , Vignesh Raghavendra , Bryan Brattlof , Praneeth Bajjuri , u-boot@lists.denx.de Subject: Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../ Message-ID: <20230716151205.GR2066889@bill-the-cat> References: <20230711212048.1340990-1-j-kacines@ti.com> <20230711212048.1340990-2-j-kacines@ti.com> <20230713225441.GR2066889@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1Nns4G+v9UvJ3lns" Content-Disposition: inline In-Reply-To: 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.8 at phobos.denx.de X-Virus-Status: Clean --1Nns4G+v9UvJ3lns Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Thu, 13 Jul 2023 at 16:54, Tom Rini wrote: > > > > On Wed, Jul 12, 2023 at 08:00:28AM -0600, Simon Glass wrote: > > > Hi Jason, > > > > > > On Tue, 11 Jul 2023 at 16:29, Jason Kacines wrote: > > > > > > > > Add support to config fragments (.config) located in the /board > > > > directory. This will allow only base defconfigs to live in /configs= and > > > > > > Does this mean defconfigs? > > > > This looks like it would cover defconfig files too, but the initial > > motivation is config fragments. See > > https://patchwork.ozlabs.org/project/uboot/patch/20230606071850.270001-= 5-clamor95@gmail.com/ > > for another example. > > > > > > all fragments to live in their respective device directory in /boar= d/.. > > > > > > Why do we want this? The patch should have a motivation. > > > > I've asked a few people to look in to this because we have a lot of > > cases today of N _defconfig files where we could really instead have 1 > > _defconfig file and N config fragment files. But I do not want them > > living in the top level configs directory as that will get even more > > unmanageable. >=20 > OK I see, thank you. The patch still needs this motivation though. So you're saying you want the message re-worded? > > What's not in this patch (and not an ask at this point) is figuring out > > how buildman could handle "foo_defconfig bar.config" as the required > > config target. >=20 > Indeed. Also, should they appear in the boards.cfg list? I doubt it? I'm not sure yet how we address getting buildman to know about valid additional combinations. Take the example of something like: som_vendor_carrier_defconfig + som_vendor_imx7_som.config + emmc_boot_instead.config + customer_production_tweaks.config How would you want buildman to know about that? Does it even really need to, on the other hand? And that's not I think an uncommon example, it's just splitting colibri_imx7_emmc_defconfig in to how it would be used by someone taking that carrier+som to production, with their own touchscreen and a few other tweaks in the dtb that needs to be passed to linux. Or the mnt reform with whatever SOM/COM you happen to have for it. --=20 Tom --1Nns4G+v9UvJ3lns Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmS0CMUACgkQFHw5/5Y0 tyyg3QwAnFIbky4UKiwM+gzpPy2WrHUjFBqVTQVBtLIvOwlifao7aSY79s6Gkfe4 aFpUzihUmLG4qse46e9aqgwflrCKkWazGGp7MhK6AO9mTGuJVdqMpdJb8n9iCJ0p ehFs7SgsUqmfXelcvkckcx2uWONseUWLW3Z97LcbNrJEgzSM/aIKJXPjCQ4QSIsx s7YMV2xkTxeyuaOKqRz6iuzlLD/ksmAjWo8H0bl6lZ7TPIFngxd4zbimwZXQRBFT B2yCtnq/ockNUixxFjTugXR5cl8KxaDutuSjP0IwXTzwKEc9M8VTALkfttb5tQb4 fw7uDJtcS6aIjoVulZqG4wj1bnE1LRUIbQd5SLnaSYaIedXVuLkZwTI9m5gJjzjK cK+V06gN85gciqmgsWxmP75i+pjHy+1s4M9kkbswDpizg5CdAE3oiS0RnotNzBhX blq2dL29qE3loPYmwG1vpi4wZm7WfAkuOZOAnA3A96p2/XoLA7tsUGn/mGrtpGdc MKGu4Zrj =p/sl -----END PGP SIGNATURE----- --1Nns4G+v9UvJ3lns--