U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@google.com>
Cc: Jason Kacines <j-kacines@ti.com>, Andrew Davis <afd@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>, Bryan Brattlof <bb@ti.com>,
	Praneeth Bajjuri <praneeth@ti.com>,
	u-boot@lists.denx.de
Subject: Re: [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../
Date: Sun, 16 Jul 2023 11:12:05 -0400	[thread overview]
Message-ID: <20230716151205.GR2066889@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ2YP8XLSWh3j4Oe0BC2LLuPDxOQiupyiCBvj7xoGpsD7g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

On Sat, Jul 15, 2023 at 05:40:35PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 13 Jul 2023 at 16:54, Tom Rini <trini@konsulko.com> 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 <j-kacines@ti.com> 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 /board/..
> > >
> > > 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.
> 
> 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.
> 
> 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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2023-07-16 15:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 21:20 [RFC PATCH 0/3] Minimal platform configuration Jason Kacines
2023-07-11 21:20 ` [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../ Jason Kacines
2023-07-12 14:00   ` Simon Glass
2023-07-13 22:54     ` Tom Rini
2023-07-15 23:40       ` Simon Glass
2023-07-16 15:12         ` Tom Rini [this message]
2023-07-19  1:07           ` Simon Glass
2023-07-19 13:34             ` Tom Rini
2023-07-27  0:49               ` Simon Glass
2023-08-07 22:15   ` [PATCH] doc: Begin adding a best practices document for board ports Tom Rini
2023-08-08 20:12     ` Heinrich Schuchardt
2023-08-08 20:36     ` [v2] " Tom Rini
2023-08-09  2:03       ` Simon Glass
2023-08-09 17:17   ` [RFC PATCH 1/3] scripts: kconfig: Add config fragment support in board/../ Tom Rini
2023-07-11 21:20 ` [RFC PATCH 2/3] configs: Add am62x wakeup defconfigs Jason Kacines
2023-07-11 21:20 ` [RFC PATCH 3/3] board: ti: am62x: Add am62x_evm defconfig fragments Jason Kacines
2023-07-12 14:00 ` [RFC PATCH 0/3] Minimal platform configuration Simon Glass
2023-07-13 22:34   ` Nishanth Menon
2023-07-15 23:40     ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230716151205.GR2066889@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=afd@ti.com \
    --cc=bb@ti.com \
    --cc=j-kacines@ti.com \
    --cc=praneeth@ti.com \
    --cc=sjg@google.com \
    --cc=u-boot@lists.denx.de \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox