All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>,
	"Marek Vasut" <marex@denx.de>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"Bin Meng" <bmeng.cn@gmail.com>, "Stefan Roese" <sr@denx.de>,
	"Marek Behún" <marek.behun@nic.cz>,
	"Sean Anderson" <seanga2@gmail.com>,
	"Aaron Williams" <awilliams@marvell.com>
Subject: Re: RFC: Support for U-Boot phases in Kconfig
Date: Wed, 11 Aug 2021 17:19:11 -0400	[thread overview]
Message-ID: <20210811211911.GM858@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ24W5_m-oLXcL69s3zeuXxkWtErsm5U0+YGwHO84EQL0g@mail.gmail.com>

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

On Wed, Aug 11, 2021 at 12:28:13PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 11 Aug 2021 at 09:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Aug 11, 2021 at 08:26:38AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 11 Aug 2021 at 08:17, Tom Rini <trini@konsulko.com> 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 <trini@konsulko.com> 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 <trini@konsulko.com> wrote:
> > > > > > [snip]
> > > > > > > > I need to take another pass at converting a bunch of symbols, to see
> > > > > > > > where we're at.  Probably the biggest chunk of progress next would be to
> > > > > > > > start converting CONFIG_SYS_xxx to SYS_xxx and moving defines out of
> > > > > > > > config.h and in to something else.  I'm taking a peek at some of 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 priority
> > > > > > > than a Kconfig change.
> > > > > > >
> > > > > > > I was expecting that the config.h files would go away and we would 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, well, 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.
> > >
> > > OK I'll take a look. Other things in progress I can think of are:
> > >
> > > - 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
> 
> Yes, I'm going to send a patch for serial and GPIO.

OK.  It would be good to know then how many platforms are unmigrated.
And I need to cycle back to the list of non-DM migrated boards thread.

> > using DM on platforms where dynamic selection/detection isn't a
> > functional win.
> 
> Assuming it is about 20KB added (plus devicetree), enabling OF_CONTROL
> seems worth it to me. For SPL I would like to see more adoption of
> your of-platdata idea.

20KiB is a lot.  It's not a huge deal when we start talking about some
sort of dynamic detection being useful.  Or "we were passed a dtb by
prior stage, use and pass along".  But there's still new designs where
neither of those are the case.  And tons of legacy designs we still have
users of.

But it's also one of those "not right this minute" topics.

[snip]
> > 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.
> 
> OK I see. The defconfig file seems to be in the Kconfig now...so I
> suppose I don't fully understand that.

Er, what?

-- 
Tom

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

  reply	other threads:[~2021-08-11 21:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-07 22:23 RFC: Support for U-Boot phases in Kconfig Simon Glass
2021-08-09 19:11 ` Tom Rini
2021-08-10 14:58   ` Simon Glass
2021-08-10 19:38     ` Tom Rini
2021-08-11 12:56       ` Simon Glass
2021-08-11 13:47         ` Tom Rini
2021-08-11 14:03           ` Simon Glass
2021-08-11 14:17             ` Tom Rini
2021-08-11 14:26               ` Simon Glass
2021-08-11 15:40                 ` Tom Rini
2021-08-11 18:28                   ` Simon Glass
2021-08-11 21:19                     ` Tom Rini [this message]
2021-08-11 20:14               ` Sean Anderson
2021-08-11 20:42                 ` Tom Rini
2021-08-11 14:02         ` Tom Rini
2021-08-11 14:11           ` Simon Glass
2021-08-11 14:31             ` Tom Rini
2021-08-11 14:47               ` Simon Glass
2021-08-11 21:04                 ` Tom Rini
2021-08-11  9:57   ` Grant Likely
2021-08-11 12:58     ` Simon Glass
2021-08-11 13:47       ` Grant Likely
2021-08-11 13:52         ` Simon Glass
2021-08-09 22:31 ` Sean Anderson
2021-08-10 20:32   ` 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=20210811211911.GM858@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=awilliams@marvell.com \
    --cc=bmeng.cn@gmail.com \
    --cc=marek.behun@nic.cz \
    --cc=marex@denx.de \
    --cc=seanga2@gmail.com \
    --cc=sjg@chromium.org \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    --cc=yamada.masahiro@socionext.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.