Hi Masahiro,
After merging the kbuild tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/module.h:18,
from drivers/mfd/omap-usb-tll.c:21:
drivers/mfd/omap-usb-tll.c:462:26: error: expected ',' or ';' before 'USBHS_DRIVER_NAME'
MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
^~~~~~~~~~~~~~~~~
include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO'
= __MODULE_INFO_PREFIX __stringify(tag) "=" info
^~~~
include/linux/module.h:164:30: note: in expansion of macro 'MODULE_INFO'
#define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
^~~~~~~~~~~
drivers/mfd/omap-usb-tll.c:462:1: note: in expansion of macro 'MODULE_ALIAS'
MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
^~~~~~~~~~~~
Caused by commit
6a26793a7891 ("moduleparam: Save information about built-in modules in separate file")
USBHS_DRIVER_NAME is not defined and this kbuild tree change has
exposed it. It has been this way since commit
16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver")
From v3.7-rc1 in 2012.
I have applied the following patch for today.
From: Stephen Rothwell <[email protected]>
Date: Mon, 6 May 2019 09:39:14 +1000
Subject: [PATCH] mfd: omap: remove unused MODULE_ALIAS from omap-usb-tll.c
USBHS_DRIVER_NAME has never been defined, so this cannot have ever
been used.
Signed-off-by: Stephen Rothwell <[email protected]>
---
drivers/mfd/omap-usb-tll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 446713dbee27..1cc8937e8bec 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL_GPL(omap_tll_disable);
MODULE_AUTHOR("Keshava Munegowda <[email protected]>");
MODULE_AUTHOR("Roger Quadros <[email protected]>");
-MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
+// MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("usb tll driver for TI OMAP EHCI and OHCI controllers");
--
2.20.1
--
Cheers,
Stephen Rothwell
Hi Paul,
In today's linux-next build testing,
more "make ... explicitly non-modular"
candidates showed up.
arch/arm/plat-omap/dma.c
drivers/clocksource/timer-ti-dm.c
drivers/mfd/omap-usb-host.c
drivers/mfd/omap-usb-tll.c
Would you send patches?
I think EXPORT_SYMBOL_GPL() in omap-usb-tll.c
are also unnecessary.
Thanks.
---------- Forwarded message ---------
From: Stephen Rothwell <[email protected]>
Date: Mon, May 6, 2019 at 8:51 AM
Subject: linux-next: build failure after merge of the kbuild tree
To: Masahiro Yamada <[email protected]>
Cc: Linux Next Mailing List <[email protected]>, Linux Kernel
Mailing List <[email protected]>, Alexey Gladkov
<[email protected]>, Keshava Munegowda <[email protected]>,
Samuel Ortiz <[email protected]>
Hi Masahiro,
After merging the kbuild tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/module.h:18,
from drivers/mfd/omap-usb-tll.c:21:
drivers/mfd/omap-usb-tll.c:462:26: error: expected ',' or ';' before
'USBHS_DRIVER_NAME'
MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
^~~~~~~~~~~~~~~~~
include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO'
= __MODULE_INFO_PREFIX __stringify(tag) "=" info
^~~~
include/linux/module.h:164:30: note: in expansion of macro 'MODULE_INFO'
#define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
^~~~~~~~~~~
drivers/mfd/omap-usb-tll.c:462:1: note: in expansion of macro 'MODULE_ALIAS'
MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
^~~~~~~~~~~~
Caused by commit
6a26793a7891 ("moduleparam: Save information about built-in modules
in separate file")
USBHS_DRIVER_NAME is not defined and this kbuild tree change has
exposed it. It has been this way since commit
16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver")
From v3.7-rc1 in 2012.
I have applied the following patch for today.
From: Stephen Rothwell <[email protected]>
Date: Mon, 6 May 2019 09:39:14 +1000
Subject: [PATCH] mfd: omap: remove unused MODULE_ALIAS from omap-usb-tll.c
USBHS_DRIVER_NAME has never been defined, so this cannot have ever
been used.
Signed-off-by: Stephen Rothwell <[email protected]>
---
drivers/mfd/omap-usb-tll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 446713dbee27..1cc8937e8bec 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL_GPL(omap_tll_disable);
MODULE_AUTHOR("Keshava Munegowda <[email protected]>");
MODULE_AUTHOR("Roger Quadros <[email protected]>");
-MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
+// MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("usb tll driver for TI OMAP EHCI and OHCI controllers");
--
2.20.1
--
Cheers,
Stephen Rothwell
--
Best Regards
Masahiro Yamada
[Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019 (Mon 11:19) Masahiro Yamada wrote:
> Hi Paul,
>
> In today's linux-next build testing,
> more "make ... explicitly non-modular"
> candidates showed up.
>
Hi Masahiro,
I am not 100% clear on what you are asking me. There are lots and lots
of these in the kernel.... many fixed, and many remain unfortunately.
> arch/arm/plat-omap/dma.c
> drivers/clocksource/timer-ti-dm.c
> drivers/mfd/omap-usb-host.c
> drivers/mfd/omap-usb-tll.c
None of these are "new". I just checked, and I have had patches for all
these for a long time, in my personal queue, found by my audits.
> Would you send patches?
It isn't that simple. I wish it was. Some subsystem maintainers are
glad to take the patches, and some think they are a waste of time and
reject them immediately. Some I've sent just simply get "crickets".
What that means is, that I need to look at each maintainer's
requirements, and ensure the patch and commit log are matching
expectatins - I will not just spam out hundreds of patches across all
subsystems. Anyone who has spent considerable time in linux development
knows that is a recipe for failure.
So I need to work across each subsystem - one at a time, with their
individual maintainer requirements in mind, and if you look at git
history, you will see that has been what I've tried to do when I had
free time to work on fixing these across the whole linux tree.
But fortunately, none of these represent a CVE/security issue, so I've
never had a reason to try and pretend there was any reason for an
immediate fix/merge - they just represent a better attention to detail
in the code we merge and support that I'd like to see happen tree-wide.
I appreciate that you are also interested in seeing all these fixed, and
I also wish they could all be solved in one version, but unfortunately I
don't think that is pragmatic. So in the meantime, I will continue to
chip away at things when we are early in the dev cycle and not starting
the two week merge window, as we are just now.
Thanks,
Paul.
--
>
> I think EXPORT_SYMBOL_GPL() in omap-usb-tll.c
> are also unnecessary.
>
> Thanks.
>
>
>
> ---------- Forwarded message ---------
> From: Stephen Rothwell <[email protected]>
> Date: Mon, May 6, 2019 at 8:51 AM
> Subject: linux-next: build failure after merge of the kbuild tree
> To: Masahiro Yamada <[email protected]>
> Cc: Linux Next Mailing List <[email protected]>, Linux Kernel
> Mailing List <[email protected]>, Alexey Gladkov
> <[email protected]>, Keshava Munegowda <[email protected]>,
> Samuel Ortiz <[email protected]>
>
>
> Hi Masahiro,
>
> After merging the kbuild tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/module.h:18,
> from drivers/mfd/omap-usb-tll.c:21:
> drivers/mfd/omap-usb-tll.c:462:26: error: expected ',' or ';' before
> 'USBHS_DRIVER_NAME'
> MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> ^~~~~~~~~~~~~~~~~
> include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO'
> = __MODULE_INFO_PREFIX __stringify(tag) "=" info
> ^~~~
> include/linux/module.h:164:30: note: in expansion of macro 'MODULE_INFO'
> #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> ^~~~~~~~~~~
> drivers/mfd/omap-usb-tll.c:462:1: note: in expansion of macro 'MODULE_ALIAS'
> MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> ^~~~~~~~~~~~
>
> Caused by commit
>
> 6a26793a7891 ("moduleparam: Save information about built-in modules
> in separate file")
>
> USBHS_DRIVER_NAME is not defined and this kbuild tree change has
> exposed it. It has been this way since commit
>
> 16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver")
>
> From v3.7-rc1 in 2012.
>
> I have applied the following patch for today.
>
> From: Stephen Rothwell <[email protected]>
> Date: Mon, 6 May 2019 09:39:14 +1000
> Subject: [PATCH] mfd: omap: remove unused MODULE_ALIAS from omap-usb-tll.c
>
> USBHS_DRIVER_NAME has never been defined, so this cannot have ever
> been used.
>
> Signed-off-by: Stephen Rothwell <[email protected]>
> ---
> drivers/mfd/omap-usb-tll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> index 446713dbee27..1cc8937e8bec 100644
> --- a/drivers/mfd/omap-usb-tll.c
> +++ b/drivers/mfd/omap-usb-tll.c
> @@ -459,7 +459,7 @@ EXPORT_SYMBOL_GPL(omap_tll_disable);
>
> MODULE_AUTHOR("Keshava Munegowda <[email protected]>");
> MODULE_AUTHOR("Roger Quadros <[email protected]>");
> -MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> +// MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> MODULE_LICENSE("GPL v2");
> MODULE_DESCRIPTION("usb tll driver for TI OMAP EHCI and OHCI controllers");
>
> --
> 2.20.1
>
> --
> Cheers,
> Stephen Rothwell
>
>
> --
> Best Regards
> Masahiro Yamada
Hi Paul,
On Mon, May 6, 2019 at 12:34 PM Paul Gortmaker
<[email protected]> wrote:
>
> [Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019 (Mon 11:19) Masahiro Yamada wrote:
>
> > Hi Paul,
> >
> > In today's linux-next build testing,
> > more "make ... explicitly non-modular"
> > candidates showed up.
> >
>
> Hi Masahiro,
>
> I am not 100% clear on what you are asking me. There are lots and lots
> of these in the kernel.... many fixed, and many remain unfortunately.
>
> > arch/arm/plat-omap/dma.c
> > drivers/clocksource/timer-ti-dm.c
> > drivers/mfd/omap-usb-host.c
> > drivers/mfd/omap-usb-tll.c
>
> None of these are "new". I just checked, and I have had patches for all
> these for a long time, in my personal queue, found by my audits.
OK, I saw many patches from you
addressing this issue,
so I just thought you might be motivated to
fix them.
Anyway, I have a reason to fix them
because a patch in my tree is causing build errors.
So, I will do something for them
if you do not have a plan to send patches soon.
Thanks.
> > Would you send patches?
>
> It isn't that simple. I wish it was. Some subsystem maintainers are
> glad to take the patches, and some think they are a waste of time and
> reject them immediately. Some I've sent just simply get "crickets".
>
> What that means is, that I need to look at each maintainer's
> requirements, and ensure the patch and commit log are matching
> expectatins - I will not just spam out hundreds of patches across all
> subsystems. Anyone who has spent considerable time in linux development
> knows that is a recipe for failure.
>
> So I need to work across each subsystem - one at a time, with their
> individual maintainer requirements in mind, and if you look at git
> history, you will see that has been what I've tried to do when I had
> free time to work on fixing these across the whole linux tree.
>
> But fortunately, none of these represent a CVE/security issue, so I've
> never had a reason to try and pretend there was any reason for an
> immediate fix/merge - they just represent a better attention to detail
> in the code we merge and support that I'd like to see happen tree-wide.
>
> I appreciate that you are also interested in seeing all these fixed, and
> I also wish they could all be solved in one version, but unfortunately I
> don't think that is pragmatic. So in the meantime, I will continue to
> chip away at things when we are early in the dev cycle and not starting
> the two week merge window, as we are just now.
>
> Thanks,
> Paul.
> --
>
> >
> > I think EXPORT_SYMBOL_GPL() in omap-usb-tll.c
> > are also unnecessary.
> >
> > Thanks.
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: Stephen Rothwell <[email protected]>
> > Date: Mon, May 6, 2019 at 8:51 AM
> > Subject: linux-next: build failure after merge of the kbuild tree
> > To: Masahiro Yamada <[email protected]>
> > Cc: Linux Next Mailing List <[email protected]>, Linux Kernel
> > Mailing List <[email protected]>, Alexey Gladkov
> > <[email protected]>, Keshava Munegowda <[email protected]>,
> > Samuel Ortiz <[email protected]>
> >
> >
> > Hi Masahiro,
> >
> > After merging the kbuild tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > In file included from include/linux/module.h:18,
> > from drivers/mfd/omap-usb-tll.c:21:
> > drivers/mfd/omap-usb-tll.c:462:26: error: expected ',' or ';' before
> > 'USBHS_DRIVER_NAME'
> > MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> > ^~~~~~~~~~~~~~~~~
> > include/linux/moduleparam.h:26:47: note: in definition of macro '__MODULE_INFO'
> > = __MODULE_INFO_PREFIX __stringify(tag) "=" info
> > ^~~~
> > include/linux/module.h:164:30: note: in expansion of macro 'MODULE_INFO'
> > #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> > ^~~~~~~~~~~
> > drivers/mfd/omap-usb-tll.c:462:1: note: in expansion of macro 'MODULE_ALIAS'
> > MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> > ^~~~~~~~~~~~
> >
> > Caused by commit
> >
> > 6a26793a7891 ("moduleparam: Save information about built-in modules
> > in separate file")
> >
> > USBHS_DRIVER_NAME is not defined and this kbuild tree change has
> > exposed it. It has been this way since commit
> >
> > 16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver")
> >
> > From v3.7-rc1 in 2012.
> >
> > I have applied the following patch for today.
> >
> > From: Stephen Rothwell <[email protected]>
> > Date: Mon, 6 May 2019 09:39:14 +1000
> > Subject: [PATCH] mfd: omap: remove unused MODULE_ALIAS from omap-usb-tll.c
> >
> > USBHS_DRIVER_NAME has never been defined, so this cannot have ever
> > been used.
> >
> > Signed-off-by: Stephen Rothwell <[email protected]>
> > ---
> > drivers/mfd/omap-usb-tll.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
> > index 446713dbee27..1cc8937e8bec 100644
> > --- a/drivers/mfd/omap-usb-tll.c
> > +++ b/drivers/mfd/omap-usb-tll.c
> > @@ -459,7 +459,7 @@ EXPORT_SYMBOL_GPL(omap_tll_disable);
> >
> > MODULE_AUTHOR("Keshava Munegowda <[email protected]>");
> > MODULE_AUTHOR("Roger Quadros <[email protected]>");
> > -MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> > +// MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
> > MODULE_LICENSE("GPL v2");
> > MODULE_DESCRIPTION("usb tll driver for TI OMAP EHCI and OHCI controllers");
> >
> > --
> > 2.20.1
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> >
> > --
> > Best Regards
> > Masahiro Yamada
>
>
--
Best Regards
Masahiro Yamada
[Re: Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019 (Mon 21:07) Masahiro Yamada wrote:
> Hi Paul,
>
>
> On Mon, May 6, 2019 at 12:34 PM Paul Gortmaker
> <[email protected]> wrote:
> >
> > [Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019 (Mon 11:19) Masahiro Yamada wrote:
> >
> > > Hi Paul,
> > >
> > > In today's linux-next build testing,
> > > more "make ... explicitly non-modular"
> > > candidates showed up.
> > >
> >
> > Hi Masahiro,
> >
> > I am not 100% clear on what you are asking me. There are lots and lots
> > of these in the kernel.... many fixed, and many remain unfortunately.
> >
> > > arch/arm/plat-omap/dma.c
> > > drivers/clocksource/timer-ti-dm.c
> > > drivers/mfd/omap-usb-host.c
> > > drivers/mfd/omap-usb-tll.c
> >
> > None of these are "new". I just checked, and I have had patches for all
> > these for a long time, in my personal queue, found by my audits.
>
>
> OK, I saw many patches from you
> addressing this issue,
> so I just thought you might be motivated to
> fix them.
>
> Anyway, I have a reason to fix them
> because a patch in my tree is causing build errors.
I understand now. I missed the connection between these drivers and the
Kbuild change when I read this last night. Sorry about that.
I can send the changes to those four files, but since I can't guarantee
they will be merged quickly (or at all!) - that will leave the commit in
the Kbuild tree causing build regressions for days or likely even weeks.
> So, I will do something for them
> if you do not have a plan to send patches soon.
I will be happy to send them, but we just opened the two week merge
window, and a lot of maintainers don't like getting sent new patches
until the two week merge window has closed - so we should avoid that.
I'm not sure how you would like to proceed - one way would be that we
get the drivers above changed in 5.2 and you delay your kbuild change
until we start v5.3 - to that end I'd be happy to add the Kbuild change
to my internal build testing in the meantime, if you would like.
Now that I understand the problem, let me know what you would like to
do, and I'll do what I can to help out.
Thanks,
Paul.
Hi Paul,
On Mon, May 6, 2019 at 11:23 PM Paul Gortmaker
<[email protected]> wrote:
>
> [Re: Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019 (Mon 21:07) Masahiro Yamada wrote:
>
> > Hi Paul,
> >
> >
> > On Mon, May 6, 2019 at 12:34 PM Paul Gortmaker
> > <[email protected]> wrote:
> > >
> > > [Fwd: linux-next: build failure after merge of the kbuild tree] On 06/05/2019 (Mon 11:19) Masahiro Yamada wrote:
> > >
> > > > Hi Paul,
> > > >
> > > > In today's linux-next build testing,
> > > > more "make ... explicitly non-modular"
> > > > candidates showed up.
> > > >
> > >
> > > Hi Masahiro,
> > >
> > > I am not 100% clear on what you are asking me. There are lots and lots
> > > of these in the kernel.... many fixed, and many remain unfortunately.
> > >
> > > > arch/arm/plat-omap/dma.c
> > > > drivers/clocksource/timer-ti-dm.c
> > > > drivers/mfd/omap-usb-host.c
> > > > drivers/mfd/omap-usb-tll.c
> > >
> > > None of these are "new". I just checked, and I have had patches for all
> > > these for a long time, in my personal queue, found by my audits.
> >
> >
> > OK, I saw many patches from you
> > addressing this issue,
> > so I just thought you might be motivated to
> > fix them.
> >
> > Anyway, I have a reason to fix them
> > because a patch in my tree is causing build errors.
>
> I understand now. I missed the connection between these drivers and the
> Kbuild change when I read this last night. Sorry about that.
>
> I can send the changes to those four files, but since I can't guarantee
> they will be merged quickly (or at all!) - that will leave the commit in
> the Kbuild tree causing build regressions for days or likely even weeks.
>
> > So, I will do something for them
> > if you do not have a plan to send patches soon.
>
> I will be happy to send them, but we just opened the two week merge
> window, and a lot of maintainers don't like getting sent new patches
> until the two week merge window has closed - so we should avoid that.
>
> I'm not sure how you would like to proceed - one way would be that we
> get the drivers above changed in 5.2 and you delay your kbuild change
> until we start v5.3 - to that end I'd be happy to add the Kbuild change
> to my internal build testing in the meantime, if you would like.
>
> Now that I understand the problem, let me know what you would like to
> do, and I'll do what I can to help out.
I decided to merge minimal changes to my kbuild tree
since I did not want to delay the kbuild patch.
I got some Ack tags, so I applied this patch:
https://patchwork.kernel.org/patch/10931673/
I appreciate if you could fix those files in a complete way,
but there is no more reason to rush.
> Thanks,
> Paul.
--
Best Regards
Masahiro Yamada