Remove MODULE_ALIAS() calls that take undefined macro
mainline inclusion from mainline-v5.2-rc1 commit 4c11edfc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I46CWD?from=project-issue CVE: NA In file included from /builds/linux/include/linux/module.h:19, from /builds/linux/arch/arm/plat-omap/dma.c:28: /builds/linux/arch/arm/plat-omap/dma.c:1452:26: error: expected ',' or ';' before 'DRIVER_NAME' 1452 | MODULE_ALIAS("platform:" DRIVER_NAME); | ^~~~~~~~~~~ /builds/linux/include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO' 26 | = __MODULE_INFO_PREFIX __stringify(tag) "=" info | ^~~~ /builds/linux/include/linux/module.h:166:30: note: in expansion of macro 'MODULE_INFO' 166 | #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias) | ^~~~~~~~~~~ /builds/linux/arch/arm/plat-omap/dma.c:1452:1: note: in expansion of macro 'MODULE_ALIAS' 1452 | MODULE_ALIAS("platform:" DRIVER_NAME); | ^~~~~~~~~~~~ make[2]: *** [/builds/linux/scripts/Makefile.build:303: arch/arm/plat-omap/dma.o] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [/builds/linux/Makefile:1070: arch/arm/plat-omap] Error 2 --------------------------------- These files do not define (USBHS_)DRIVER_NAME. Yet, they can be successfully compiled because they are never built as a module by anyone, i.e, the MODULE_ALIAS() calls are always no-op. A problem showed up when a patch "moduleparam: Save information about built-in modules in separate file" was applied. With this new feature, MODULE_*() will be populated even if the callers are built-in. To avoid the build errors, the lines referencing to the undefined macro must be removed. The complete fix is to remove all MODULE_* and #include <linux/module.h> like many "make ... explicitly non-modular" commits did. For now, I am touching only the offending lines. Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Hanjun Guo <guohanjun@huawei.com> Reviewed-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com>
Loading
Please sign in to comment