Re: [PATCH] Documentation: warn users not to use select on choice options in Kconfig

Hi Nicolas,

On 8/2/26 20:13, Nicolas Schier wrote:
> On Wed, Jul 15, 2026 at 11:01:49PM +0100, Julian Braha wrote:
>> Hengelein's master thesis about Kconfig from 2015 wrote that 'select'
>> does not work on member options inside of a 'choice'.
> 
> is this true also for 'imply'?  

Yes, the same problem goes for imply. But I didn't find any of these
'imply-choice' instances in use. Of course, if we're going to warn /
error for select, then it makes sense to do the same for imply.

> Adding the check to kconfig seems to be
> pretty simple:
> 
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index b2d8d4e11e07..149d3ee59b58 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -287,6 +287,11 @@ static void sym_check_prop(struct symbol *sym)
>  				    "'%s' has wrong type. '%s' only "
>  				    "accept arguments of bool and "
>  				    "tristate type", sym2->name, use);
> +			if (sym_is_choice_value(sym2))
> +				prop_warn(prop,
> +				    "config symbol '%s' uses %s for '%s', "
> +				    "but '%s' is a choice value", sym->name,
> +				    use, sym2->name, sym2->name);
>  			break;
>  		case P_RANGE:
>  			if (sym->type != S_INT && sym->type != S_HEX)
> 
> which currently reveals
> 
> kernel/time/Kconfig:136:warning: config symbol 'NO_HZ_FULL' uses select for 'VIRT_CPU_ACCOUNTING_GEN', but 'VIRT_CPU_ACCOUNTING_GEN' is a choice value
> drivers/mtd/maps/Kconfig:104:warning: config symbol 'MTD_PHYSMAP_IXP4XX' uses select for 'MTD_CFI_BE_BYTE_SWAP', but 'MTD_CFI_BE_BYTE_SWAP' is a choice value
> drivers/tee/qcomtee/Kconfig:8:warning: config symbol 'QCOMTEE' uses select for 'QCOM_TZMEM_MODE_SHMBRIDGE', but 'QCOM_TZMEM_MODE_SHMBRIDGE' is a choice value
> 
> on linux-next, with the NO_HZ_FULL also being addressed by Julian [1].
> 
> Julian, please call out if you want help for pushing these.

Thanks for offering :)

I actually detected 5 of these across all architectures, and already
submitted patches for all of them (thank you, Arnd, for all of your
help):
1.
https://lore.kernel.org/all/[email protected]/
2.
https://lore.kernel.org/all/[email protected]/
3.
https://lore.kernel.org/all/[email protected]/
4.
https://lore.kernel.org/all/[email protected]/

With #5 already in linux-next:
5.
https://lore.kernel.org/all/[email protected]/

> I am considering to prepare a patch and add it for kbuild-for-next (but
> not to kbuild-next) to raise attention.

I think the Kconfig interpreter should completely error out for these,
but of course, we need to wait all of these patches to be applied first.

- Julian Braha