All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: Tom Rini <trini@konsulko.com>
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 08:03:00 -0600	[thread overview]
Message-ID: <CAPnjgZ1Brdp+iNFaaup6VjJhAaV1WAa41s5hdvao9Ws+ULFeUw@mail.gmail.com> (raw)
In-Reply-To: <20210811134732.GV858@bill-the-cat>

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.

> 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 (they
> do math based on other symbols) rather than just as evaluate-and-set.

We can either evaluate them and put the answer in as the defconfig
value...or perhaps ask Masahiro to support evaluation in kconfig?!

> Right now, a little more than half of the unmigrated symbols are
> CONFIG_SYS_xxx things and those likely should become SYS_xxx things.  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 devcetree.

Some of the DM migrations will help - e.g. for I2C. NAND seems to have
a lot - who is the 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...

Regards,
SImon

  reply	other threads:[~2021-08-11 14:03 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 [this message]
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
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=CAPnjgZ1Brdp+iNFaaup6VjJhAaV1WAa41s5hdvao9Ws+ULFeUw@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=awilliams@marvell.com \
    --cc=bmeng.cn@gmail.com \
    --cc=marek.behun@nic.cz \
    --cc=marex@denx.de \
    --cc=seanga2@gmail.com \
    --cc=sr@denx.de \
    --cc=trini@konsulko.com \
    --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.