From: Tony Lindgren <tony@atomide.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kbuild@vger.kernel.org,
Alexey Gladkov <gladkov.alexey@gmail.com>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
linux-kernel@vger.kernel.org,
Russell King <linux@armlinux.org.uk>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-omap@vger.kernel.org, Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] Remove MODULE_ALIAS() calls that take undefined macro
Date: Mon, 6 May 2019 14:11:20 -0700 [thread overview]
Message-ID: <20190506211120.GR8007@atomide.com> (raw)
In-Reply-To: <6d8e2880-0cc0-a7d8-1d42-4401e15e3ac9@linaro.org>
* Daniel Lezcano <daniel.lezcano@linaro.org> [190506 17:40]:
> On 06/05/2019 19:28, Masahiro Yamada wrote:
> > 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" is applied. With this new feature,
> > MODULE_*() are 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 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>
Thanks, please feel free to merge together with your series:
Acked-by: Tony Lindgren <tony@atomide.com>
Or if you want me to queue it separately, please let me know.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-06 21:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 17:28 [PATCH] Remove MODULE_ALIAS() calls that take undefined macro Masahiro Yamada
2019-05-06 17:39 ` Daniel Lezcano
2019-05-06 21:11 ` Tony Lindgren [this message]
2019-05-08 11:37 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190506211120.GR8007@atomide.com \
--to=tony@atomide.com \
--cc=aaro.koskinen@iki.fi \
--cc=daniel.lezcano@linaro.org \
--cc=gladkov.alexey@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).