[U-Boot] very short list of "badref selects" in u-boot source

rather than go to the trouble of whipping up a wiki page, i can present this in a short post to the list. here's the list of what my script identified as "badref selects" -- those identifiers for which there is a Kconfig line of the form:
select X
where there is no corresponding:
config X
the entire list:
BOOTM_LINUX CONFIG_EHCI_HCD_INIT_AFTER_RESET CONFIG_MPC8xx_WATCHDOG CPU_ARM926EJS1 CRC32 GPIO MSCC_BITBANG_SPI_GPIO SPL_DISABLE_OF_CONTROL VEXPRESS_CLK
first, the two with the "CONFIG_" prefix are obvious typos which should have those prefixes removed.
as for the rest, as one example, consider "CRC32":
$ git grep "select CRC32" cmd/Kconfig: select CRC32 cmd/Kconfig: select CRC32 drivers/mtd/ubi/Kconfig: select CRC32 fs/btrfs/Kconfig: select CRC32C $
there is no matching "config CRC32" anywhere, although there is:
include/image.h:# define CONFIG_CRC32 /* FIT images need CRC32 support */
in any event, others are welcome to decide what to do about that short list of suspicious "select" directives. i am not trying to be annoying, i am merely succeeding.
rday

On Sat, Apr 13, 2019 at 8:43 AM Robert P. J. Day rpjday@crashcourse.ca wrote:
rather than go to the trouble of whipping up a wiki page, i can present this in a short post to the list. here's the list of what my script identified as "badref selects" -- those identifiers for which there is a Kconfig line of the form:
select X
where there is no corresponding:
config X
the entire list:
BOOTM_LINUX CONFIG_EHCI_HCD_INIT_AFTER_RESET CONFIG_MPC8xx_WATCHDOG CPU_ARM926EJS1 CRC32 GPIO MSCC_BITBANG_SPI_GPIO SPL_DISABLE_OF_CONTROL VEXPRESS_CLK
first, the two with the "CONFIG_" prefix are obvious typos which should have those prefixes removed.
as for the rest, as one example, consider "CRC32":
$ git grep "select CRC32" cmd/Kconfig: select CRC32 cmd/Kconfig: select CRC32 drivers/mtd/ubi/Kconfig: select CRC32 fs/btrfs/Kconfig: select CRC32C $
there is no matching "config CRC32" anywhere, although there is:
include/image.h:# define CONFIG_CRC32 /* FIT images need CRC32 support */
in any event, others are welcome to decide what to do about that short list of suspicious "select" directives. i am not trying to be annoying, i am merely succeeding.
I had a look into a few of these. CPU_ARM926EJS1 and GPIO also appear to be typos. I've sent patches to fix them.
You're also right about CRC32. It appears that lib/Makefile has had obj-y += crc32.o (or the equivalent) for as long as I've been able to trace. Note that CRC32C does have a config option so be careful when grepping. I'll look at a series for that as well.

On Fri, 12 Apr 2019, Robert P. J. Day wrote:
rather than go to the trouble of whipping up a wiki page, i can present this in a short post to the list. here's the list of what my script identified as "badref selects" -- those identifiers for which there is a Kconfig line of the form:
select X
where there is no corresponding:
config X
the entire list:
BOOTM_LINUX CONFIG_EHCI_HCD_INIT_AFTER_RESET CONFIG_MPC8xx_WATCHDOG CPU_ARM926EJS1 CRC32 GPIO MSCC_BITBANG_SPI_GPIO SPL_DISABLE_OF_CONTROL VEXPRESS_CLK
... snip ...
between a couple patches i sent in and the more extensive submissions from chris packham, most of this list has been resolved except for three of them. a couple are isolated but i'm not sure what to do with them:
$ git grep MSCC_BITBANG_SPI_GPIO arch/mips/mach-mscc/Kconfig: select MSCC_BITBANG_SPI_GPIO $
and:
$ git grep VEXPRESS_CLK drivers/video/Kconfig: select VEXPRESS_CLK $
but it's BOOTM_LINUX that i'm unsure of:
$ git grep BOOTM_LINUX common/bootm_os.c:#ifdef CONFIG_BOOTM_LINUX include/config_defaults.h:#define CONFIG_BOOTM_LINUX 1 include/configs/xilinx_versal_mini.h:#undef CONFIG_BOOTM_LINUX include/configs/xilinx_zynqmp_mini.h:#undef CONFIG_BOOTM_LINUX include/configs/zynq_cse.h:#undef CONFIG_BOOTM_LINUX lib/optee/Kconfig: select BOOTM_LINUX scripts/config_whitelist.txt:CONFIG_BOOTM_LINUX $
it's clear that CONFIG_BOOTM_LINUX is simply defined as a hard-coded macro in some header files, so what does it then mean if a Kconfig file selects it? i've never checked what the Kbuild infrastructure does in a case like that -- would it actually define CONFIG_BOOTM_LINUX, despite the fact that there is no associated BOOTM_LINUX Kbuild option? in any event, it's definitely messy.
anyway, those are the remnants of "select" directives referring to non-existent Kbuild options.
rday
participants (2)
-
Chris Packham
-
Robert P. J. Day