[PATCH] Makefile: Add a warning about ad-hoc CONFIG options
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 ---
Makefile | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/Makefile b/Makefile index 3014788e14e..7e73e6df1ef 100644 --- a/Makefile +++ b/Makefile @@ -1132,6 +1132,16 @@ endif @# know about unless they are in Kconfig. All the existing CONFIG @# options are whitelisted, so new ones should not be added. $(call cmd,cfgcheck,u-boot.cfg) + @if [ -s include/autoconf.mk ]; then \ + echo >&2 "===================== WARNING ======================"; \ + echo >&2 "This board uses ad-hoc CONFIG options, i.e. those"; \ + echo >&2 "not defined by a Kconfig option."; \ + echo >&2 "Support for these will be dropped starting with the"; \ + echo >&2 "v2022.10 release. Please add new Kconfig options"; \ + echo >&2 "as needed, or use devicetree."; \ + echo >&2 "Failure to update may result in board removal."; \ + echo >&2 "===================================================="; \ + fi
PHONY += dtbs dtbs: dts/dt.dtb
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.
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 ?
Regards, Simon
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.
Hi Tom,
On Tue, 21 Sept 2021 at 08:49, Tom Rini trini@konsulko.com wrote:
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.
Hmm yes NAND looks a bit grim. Perhaps we can look at this when we have the env thing in and can see the possibility of fully migrated boards.
Regards, Simon
participants (2)
-
Simon Glass -
Tom Rini