From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>,
"Masahiro Yamada" <yamada.masahiro@socionext.com>,
"Bin Meng" <bmeng.cn@gmail.com>,
"Marek Behún" <marek.behun@nic.cz>,
"Pali Rohár" <pali@kernel.org>
Subject: Re: [PATCH] Makefile: Add a warning about ad-hoc CONFIG options
Date: Tue, 21 Sep 2021 10:49:25 -0400 [thread overview]
Message-ID: <20210921144925.GG8579@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ1Gvp+vctrfst9gw4pjLT=y7AiPQKryQtQPT9mkz2BxxA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
On Mon, Sep 20, 2021 at 07:11:26PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 20 Sept 2021 at 09:20, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sat, Sep 18, 2021 at 12:21:21PM -0600, Simon Glass wrote:
> >
> > > The Kconfig feature was added in 2014. Some 7 years later there are still
> > > quite a few CONFIG options that have not been migrated. It is time to
> > > close this out.
> > >
> > > Add a deadline and a warning for boards to migrate to Kconfig.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> > I agree with the sentiment. But we aren't at the point where even aside
> > from environment and a few outstanding migrations I've posted but not
> > yet pulled, that any platform is 100% clean. There's still even
> > migrated-but-in-config.h symbols seemingly everywhere.
>
> Indeed!
>
> So perhaps the trigger for this would be to have one board that
> doesn't have a config.h ?
I'm not sure. There's, largely, the ability to confirm that a
conversion is identical here, unlike with DM migrations. Setting aside
environment (which thanks for picking up again), there's a few tricky
conversions that might be best served by code updates (like
CONFIG_SYS_NAND_ECCPOS I think can be removed IF drivers are converted
to use mtd_ooblayout_get_eccbytes() instead, which is how both the Linux
Kernel, and a few more modern in-tree drivers do this today) or really
just moving information to some other header. But we shouldn't be stuck
with groups of boards that are unconverted. I feel like NAND is
probably going to be the worst subsystem to finish converting and that's
just going to highlight further "this should be updated for DM an DT.."
of which only a few users have been.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2021-09-21 14:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-18 18:21 [PATCH] Makefile: Add a warning about ad-hoc CONFIG options Simon Glass
2021-09-20 15:20 ` Tom Rini
2021-09-21 1:11 ` Simon Glass
2021-09-21 14:49 ` Tom Rini [this message]
2021-10-21 20:17 ` 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=20210921144925.GG8579@bill-the-cat \
--to=trini@konsulko.com \
--cc=bmeng.cn@gmail.com \
--cc=marek.behun@nic.cz \
--cc=pali@kernel.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox