[PATCH] Makefile: Add a warning about ad-hoc CONFIG options

[Tom Rini]

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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210921/bf8c084c/attachment.sig>