| Message ID | CAK7LNASH4CuVBjfEJsT+aBx4aLrj9j2=aOD3B4f9+Tdcm=x2pg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | linux-next: build failure after merge of the kbuild tree | expand |
[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 <sfr@canb.auug.org.au> > Date: Mon, May 6, 2019 at 8:51 AM > Subject: linux-next: build failure after merge of the kbuild tree > To: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Linux Next Mailing List <linux-next@vger.kernel.org>, Linux Kernel > Mailing List <linux-kernel@vger.kernel.org>, Alexey Gladkov > <gladkov.alexey@gmail.com>, Keshava Munegowda <keshava_mgowda@ti.com>, > Samuel Ortiz <sameo@linux.intel.com> > > > 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 <sfr@canb.auug.org.au> > 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 <sfr@canb.auug.org.au> > --- > 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 <keshava_mgowda@ti.com>"); > MODULE_AUTHOR("Roger Quadros <rogerq@ti.com>"); > -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 <paul.gortmaker@windriver.com> 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 <sfr@canb.auug.org.au> > > Date: Mon, May 6, 2019 at 8:51 AM > > Subject: linux-next: build failure after merge of the kbuild tree > > To: Masahiro Yamada <yamada.masahiro@socionext.com> > > Cc: Linux Next Mailing List <linux-next@vger.kernel.org>, Linux Kernel > > Mailing List <linux-kernel@vger.kernel.org>, Alexey Gladkov > > <gladkov.alexey@gmail.com>, Keshava Munegowda <keshava_mgowda@ti.com>, > > Samuel Ortiz <sameo@linux.intel.com> > > > > > > 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 <sfr@canb.auug.org.au> > > 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 <sfr@canb.auug.org.au> > > --- > > 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 <keshava_mgowda@ti.com>"); > > MODULE_AUTHOR("Roger Quadros <rogerq@ti.com>"); > > -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 > <paul.gortmaker@windriver.com> 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 <paul.gortmaker@windriver.com> 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 > > <paul.gortmaker@windriver.com> 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
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 <keshava_mgowda@ti.com>"); MODULE_AUTHOR("Roger Quadros <rogerq@ti.com>"); -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");