(Most recipients dropped.)
On Tue, 1 Jul 2025, Lukas Bulwahn wrote:
> From: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxxx>
>
> In the Makefile, the new build option CONFIG_CAAM_QI is defined conditioned
> on the existence of the CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI, which is
> properly defined in the Kconfig file. So, CONFIG_CAAM_QI is just a local
> alias for CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI.
>
> There is little benefit in the source code of having this slightly shorter
> alias for this configuration, but it complicates further maintenance, as
> searching for the impact of CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI
> requires to grep once, and then identify the option introduced and continue
> searching for that. Further, tools, such as cross referencers, and scripts
> to check Kconfig definitions and their use simply do not handle this
> situation. Given that this is the only incidence of such a config alias in
> the whole kernel tree, just prefer to avoid this pattern of aliasing here.
>
> Use CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI throughout the Freescale
> CAAM-Multicore platform driver backend source code.
>
> No functional change.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxxx>
... snip ...
hilariously, i was *just* about to use this symbol (CONFIG_CAAM_QI)
as an example of finding what i call "badif" Kconfig symbols --
symbols that are checked by the preprocessor but are *apparently* not
defined in any Kconfig file. i'll write a separate note about this
right away, but this very symbol was one that was flagged by my
script that turned out to be just a bit trickier than i thought; your
solution dealt with the "trickiness", though.
explanation coming shortly.
rday
