diff mbox series

[14/24] kbuild, firmware: imx: remove MODULE_LICENSE in non-modules

Message ID 20230217141059.392471-15-nick.alcock@oracle.com (mailing list archive)
State New, archived
Headers show
Series MODULE_LICENSE removals, second tranche | expand

Commit Message

Nick Alcock Feb. 17, 2023, 2:10 p.m. UTC
Since commit 8b41fc4454e ("kbuild: create modules.builtin without
Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
are used to identify modules. As a consequence, uses of the macro
in non-modules will cause modprobe to misidentify their containing
object file as a module when it is not (false positives), and modprobe
might succeed rather than failing with a suitable error message.

So remove it in the files in this commit, none of which can be built as
modules.

Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Hitomi Hasegawa <hasegawa-hitomi@fujitsu.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
---
 drivers/bus/imx-weim.c         | 1 -
 drivers/firmware/imx/imx-scu.c | 1 -
 drivers/firmware/imx/scu-pd.c  | 1 -
 3 files changed, 3 deletions(-)

Comments

Shawn Guo March 14, 2023, 1:35 a.m. UTC | #1
On Fri, Feb 17, 2023 at 02:10:49PM +0000, Nick Alcock wrote:
> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> are used to identify modules. As a consequence, uses of the macro
> in non-modules will cause modprobe to misidentify their containing
> object file as a module when it is not (false positives), and modprobe
> might succeed rather than failing with a suitable error message.
> 
> So remove it in the files in this commit, none of which can be built as
> modules.
> 
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>

Should I apply it as a fix for 6.3-rc with Cc stable tag, or can it be
a material for -next?

Shawn
Nick Alcock March 20, 2023, 10:36 a.m. UTC | #2
On 14 Mar 2023, Shawn Guo verbalised:

> On Fri, Feb 17, 2023 at 02:10:49PM +0000, Nick Alcock wrote:
>> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
>> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
>> are used to identify modules. As a consequence, uses of the macro
>> in non-modules will cause modprobe to misidentify their containing
>> object file as a module when it is not (false positives), and modprobe
>> might succeed rather than failing with a suitable error message.
>> 
>> So remove it in the files in this commit, none of which can be built as
>> modules.
>> 
>> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
>> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
>
> Should I apply it as a fix for 6.3-rc with Cc stable tag, or can it be
> a material for -next?

This is currently built against -next, but Luis has indicated an intent
to pull the lot in via -rc3 (hence my scrambling to get the series
polished up for him, tags attached etc now). So, er... yes? :)
Luis Chamberlain March 20, 2023, 9:42 p.m. UTC | #3
On Mon, Mar 20, 2023 at 10:36:15AM +0000, Nick Alcock wrote:
> On 14 Mar 2023, Shawn Guo verbalised:
> 
> > On Fri, Feb 17, 2023 at 02:10:49PM +0000, Nick Alcock wrote:
> >> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
> >> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
> >> are used to identify modules. As a consequence, uses of the macro
> >> in non-modules will cause modprobe to misidentify their containing
> >> object file as a module when it is not (false positives), and modprobe
> >> might succeed rather than failing with a suitable error message.
> >> 
> >> So remove it in the files in this commit, none of which can be built as
> >> modules.
> >> 
> >> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> >> Suggested-by: Luis Chamberlain <mcgrof@kernel.org>
> >
> > Should I apply it as a fix for 6.3-rc with Cc stable tag, or can it be
> > a material for -next?

These are not stable critical patches.

> This is currently built against -next, but Luis has indicated an intent
> to pull the lot in via -rc3 (hence my scrambling to get the series
> polished up for him, tags attached etc now). So, er... yes? :)

Those patches which don't get this simply can't benefit from future
tooling enhancements which Nick is working on which will leverage
correct mapping.

So yes, my goal is to pull up straggler patches except where some
maintainer explicitly don't want them. For instance, I will not be
taking in the patches for trees that Greg KH maintains as he would
prefer an alternative, but yet hasn't recommended an alternative
strategy to help with Nick's work.

  Luis
diff mbox series

Patch

diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 828c66bbaa67..a3a99299ad15 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -405,4 +405,3 @@  module_exit(weim_exit);
 
 MODULE_AUTHOR("Freescale Semiconductor Inc.");
 MODULE_DESCRIPTION("i.MX EIM Controller Driver");
-MODULE_LICENSE("GPL");
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index dca79caccd01..886bbc81e0b4 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -358,4 +358,3 @@  builtin_platform_driver(imx_scu_driver);
 
 MODULE_AUTHOR("Dong Aisheng <aisheng.dong@nxp.com>");
 MODULE_DESCRIPTION("IMX SCU firmware protocol driver");
-MODULE_LICENSE("GPL v2");
diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index 2a4f07423365..7e8810bdfe0e 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -421,4 +421,3 @@  builtin_platform_driver(imx_sc_pd_driver);
 
 MODULE_AUTHOR("Dong Aisheng <aisheng.dong@nxp.com>");
 MODULE_DESCRIPTION("IMX SCU Power Domain driver");
-MODULE_LICENSE("GPL v2");