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 <[email protected]>
Suggested-by: Luis Chamberlain <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Hitomi Hasegawa <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Philipp Zabel <[email protected]>
---
drivers/irqchip/irq-renesas-rzg2l.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
index 25fd8ee66565..4bbfa2b0a4df 100644
--- a/drivers/irqchip/irq-renesas-rzg2l.c
+++ b/drivers/irqchip/irq-renesas-rzg2l.c
@@ -390,4 +390,3 @@ IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
MODULE_AUTHOR("Lad Prabhakar <[email protected]>");
MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
-MODULE_LICENSE("GPL");
--
2.39.1.268.g9de2f9a303
On Fri, 24 Feb 2023 15:07:53 +0000,
Nick Alcock <[email protected]> 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 <[email protected]>
> Suggested-by: Luis Chamberlain <[email protected]>
> Cc: Luis Chamberlain <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: Hitomi Hasegawa <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Cc: Philipp Zabel <[email protected]>
> ---
> drivers/irqchip/irq-renesas-rzg2l.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> index 25fd8ee66565..4bbfa2b0a4df 100644
> --- a/drivers/irqchip/irq-renesas-rzg2l.c
> +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> @@ -390,4 +390,3 @@ IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
> IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> MODULE_AUTHOR("Lad Prabhakar <[email protected]>");
> MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> -MODULE_LICENSE("GPL");
I'm probably missing some context here, but I find it odd to drop
something that is a important piece of information because of what
looks like a tooling regression.
It also means that once a random driver gets enabled as a module, it
won't load because it is now missing a MODULE_LICENSE() annotation.
It feels like MODULE_LICENSE should instead degrade to an empty
statement when MODULE isn't defined. Why isn't this approach the
correct one?
I expect the cover letter would have some pretty good information on
this, but lore.kernel.org doesn't seem to have it at the time I write
this ("Message-ID <[email protected]> not
found").
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Fri, Feb 24, 2023 at 03:32:51PM +0000, Marc Zyngier wrote:
> On Fri, 24 Feb 2023 15:07:53 +0000,
> Nick Alcock <[email protected]> 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 <[email protected]>
> > Suggested-by: Luis Chamberlain <[email protected]>
> > Cc: Luis Chamberlain <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Cc: Hitomi Hasegawa <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: Marc Zyngier <[email protected]>
> > Cc: Philipp Zabel <[email protected]>
> > ---
> > drivers/irqchip/irq-renesas-rzg2l.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> > index 25fd8ee66565..4bbfa2b0a4df 100644
> > --- a/drivers/irqchip/irq-renesas-rzg2l.c
> > +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> > @@ -390,4 +390,3 @@ IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
> > IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> > MODULE_AUTHOR("Lad Prabhakar <[email protected]>");
> > MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> > -MODULE_LICENSE("GPL");
>
> I'm probably missing some context here, but I find it odd to drop
> something that is a important piece of information because of what
> looks like a tooling regression.
>
> It also means that once a random driver gets enabled as a module, it
> won't load because it is now missing a MODULE_LICENSE() annotation.
>
> It feels like MODULE_LICENSE should instead degrade to an empty
> statement when MODULE isn't defined. Why isn't this approach the
> correct one?
>
> I expect the cover letter would have some pretty good information on
> this, but lore.kernel.org doesn't seem to have it at the time I write
> this ("Message-ID <[email protected]> not
> found").
The right thing is to not even have this and have the module license
inferred from the SPDX tag. But for now we want to remove the tag from
things we know for sure are not modules.
Luis
On Fri, 24 Feb 2023 17:21:40 +0000,
Luis Chamberlain <[email protected]> wrote:
>
> On Fri, Feb 24, 2023 at 03:32:51PM +0000, Marc Zyngier wrote:
> > On Fri, 24 Feb 2023 15:07:53 +0000,
> > Nick Alcock <[email protected]> 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 <[email protected]>
> > > Suggested-by: Luis Chamberlain <[email protected]>
> > > Cc: Luis Chamberlain <[email protected]>
> > > Cc: [email protected]
> > > Cc: [email protected]
> > > Cc: Hitomi Hasegawa <[email protected]>
> > > Cc: Thomas Gleixner <[email protected]>
> > > Cc: Marc Zyngier <[email protected]>
> > > Cc: Philipp Zabel <[email protected]>
> > > ---
> > > drivers/irqchip/irq-renesas-rzg2l.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> > > index 25fd8ee66565..4bbfa2b0a4df 100644
> > > --- a/drivers/irqchip/irq-renesas-rzg2l.c
> > > +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> > > @@ -390,4 +390,3 @@ IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
> > > IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> > > MODULE_AUTHOR("Lad Prabhakar <[email protected]>");
> > > MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> > > -MODULE_LICENSE("GPL");
> >
> > I'm probably missing some context here, but I find it odd to drop
> > something that is a important piece of information because of what
> > looks like a tooling regression.
> >
> > It also means that once a random driver gets enabled as a module, it
> > won't load because it is now missing a MODULE_LICENSE() annotation.
> >
> > It feels like MODULE_LICENSE should instead degrade to an empty
> > statement when MODULE isn't defined. Why isn't this approach the
> > correct one?
> >
> > I expect the cover letter would have some pretty good information on
> > this, but lore.kernel.org doesn't seem to have it at the time I write
> > this ("Message-ID <[email protected]> not
> > found").
>
> The right thing is to not even have this and have the module license
> inferred from the SPDX tag. But for now we want to remove the tag from
> things we know for sure are not modules.
I understand that you want to remove it. I don't get why this is the
right solution. Can you please assume that, in this particular
instance, I am a complete idiot and spell it out for me?
Why isn't that a problem for modules that are compiled-in?
M.
--
Without deviation from the norm, progress is not possible.
On Fri, Feb 24, 2023 at 05:35:34PM +0000, Marc Zyngier wrote:
> On Fri, 24 Feb 2023 17:21:40 +0000,
> Luis Chamberlain <[email protected]> wrote:
> >
> > On Fri, Feb 24, 2023 at 03:32:51PM +0000, Marc Zyngier wrote:
> > > On Fri, 24 Feb 2023 15:07:53 +0000,
> > > Nick Alcock <[email protected]> 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 <[email protected]>
> > > > Suggested-by: Luis Chamberlain <[email protected]>
> > > > Cc: Luis Chamberlain <[email protected]>
> > > > Cc: [email protected]
> > > > Cc: [email protected]
> > > > Cc: Hitomi Hasegawa <[email protected]>
> > > > Cc: Thomas Gleixner <[email protected]>
> > > > Cc: Marc Zyngier <[email protected]>
> > > > Cc: Philipp Zabel <[email protected]>
> > > > ---
> > > > drivers/irqchip/irq-renesas-rzg2l.c | 1 -
> > > > 1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> > > > index 25fd8ee66565..4bbfa2b0a4df 100644
> > > > --- a/drivers/irqchip/irq-renesas-rzg2l.c
> > > > +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> > > > @@ -390,4 +390,3 @@ IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
> > > > IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> > > > MODULE_AUTHOR("Lad Prabhakar <[email protected]>");
> > > > MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> > > > -MODULE_LICENSE("GPL");
> > >
> > > I'm probably missing some context here, but I find it odd to drop
> > > something that is a important piece of information because of what
> > > looks like a tooling regression.
> > >
> > > It also means that once a random driver gets enabled as a module, it
> > > won't load because it is now missing a MODULE_LICENSE() annotation.
> > >
> > > It feels like MODULE_LICENSE should instead degrade to an empty
> > > statement when MODULE isn't defined. Why isn't this approach the
> > > correct one?
> > >
> > > I expect the cover letter would have some pretty good information on
> > > this, but lore.kernel.org doesn't seem to have it at the time I write
> > > this ("Message-ID <[email protected]> not
> > > found").
> >
> > The right thing is to not even have this and have the module license
> > inferred from the SPDX tag. But for now we want to remove the tag from
> > things we know for sure are not modules.
>
> I understand that you want to remove it. I don't get why this is the
> right solution. Can you please assume that, in this particular
> instance, I am a complete idiot and spell it out for me?
>
> Why isn't that a problem for modules that are compiled-in?
Modules that are compiled in should succeed with a modprobe call as its
already loaded. The construct we're looking for is a way to detect
things which are built-in but *could* be modules. The annotation today
is done at build time for something built-in using a file path using
modinfo.
All of the module macros which peg .modinfo section information for
built-in code can be extracted from vmlinux using objcopy -j .modinfo, and
that's exactly how modules.builtin.modinfo is built:
objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
From this we grep out the "file:" and sed it with a ^kernel prefix.
You can look at the commit 8b41fc4454e ("kbuild: create modules.builtin
without Makefile.modbuiltin or tristate.conf") which did that.
If a module is built-in then MODULE_FILE() is used we and we add a
MODULE_INFO(file, KBUILD_MODFILE), and so the modinfo exists for the
"file:" tag for it. At build time we sed for all those with a kernel prefix
to build the modules.builtin file. That file is used by modprobe to tell
us "yes your module is loaded as its built-in".
So the thing we wish to not have present is when built-in code is being
compiled but *cannot possibly* be module, and we have no way to verify that.
So one way to go about this is to simply *not* use the MODULE_LICENSE()
which cannot possibly be modules so to simplfy the build process. I
think the alternative would be to have a kconfig tristate add a new define for
the case where the tristate was y.
So something like this:
diff --git a/Makefile b/Makefile
index 197dcb83b2e1..f825d0546a7f 100644
--- a/Makefile
+++ b/Makefile
@@ -574,6 +574,7 @@ KBUILD_CFLAGS_KERNEL :=
KBUILD_RUSTFLAGS_KERNEL :=
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
+KBUILD_CFLAGS_MODULE_POSSIBLE := -DMODULE_POSSIBLE
KBUILD_RUSTFLAGS_MODULE := --cfg MODULE
KBUILD_LDFLAGS_MODULE :=
KBUILD_LDFLAGS :=
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 100a386fcd71..13f31766eee3 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -211,12 +211,15 @@ endif
endif
part-of-module = $(if $(filter $(basename $@).o, $(real-obj-m)),y)
+could-be-module = $(if $(filter $(basename $@).o, $(possible-obj-m)),y)
quiet_modtag = $(if $(part-of-module),[M], )
modkern_cflags = \
$(if $(part-of-module), \
$(KBUILD_CFLAGS_MODULE) $(CFLAGS_MODULE), \
- $(KBUILD_CFLAGS_KERNEL) $(CFLAGS_KERNEL) $(modfile_flags))
+ $(KBUILD_CFLAGS_KERNEL) $(CFLAGS_KERNEL) $(modfile_flags)) \
+ $(if $(could-be-module),, \
+ $(KBUILD_CFLAGS_MODULE_POSSIBLE)
modkern_rustflags = \
$(if $(part-of-module), \
The difficulty would be the possible-obj-m, to do it without incurring
a huge slow down on the build process.
Luis
On 24 Feb 2023, Luis Chamberlain spake thusly:
> Modules that are compiled in should succeed with a modprobe call as its
> already loaded. The construct we're looking for is a way to detect
> things which are built-in but *could* be modules. The annotation today
> is done at build time for something built-in using a file path using
> modinfo.
>
> All of the module macros which peg .modinfo section information for
> built-in code can be extracted from vmlinux using objcopy -j .modinfo, and
> that's exactly how modules.builtin.modinfo is built:
>
> objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
>
> From this we grep out the "file:" and sed it with a ^kernel prefix.
> You can look at the commit 8b41fc4454e ("kbuild: create modules.builtin
> without Makefile.modbuiltin or tristate.conf") which did that.
>
> If a module is built-in then MODULE_FILE() is used we and we add a
> MODULE_INFO(file, KBUILD_MODFILE), and so the modinfo exists for the
> "file:" tag for it. At build time we sed for all those with a kernel prefix
> to build the modules.builtin file. That file is used by modprobe to tell
> us "yes your module is loaded as its built-in".
>
> So the thing we wish to not have present is when built-in code is being
> compiled but *cannot possibly* be module, and we have no way to verify that.
>
> So one way to go about this is to simply *not* use the MODULE_LICENSE()
> which cannot possibly be modules so to simplfy the build process.
I do wonder if I should drop this excellent description (up to the place
where you start musing on alternatives) into the cover letters for the
remaining two tranches in this series, to forestall further confusion.
Any objection? (I doubt it, but it seems right to ask.)
On Mon, Feb 27, 2023 at 01:24:31PM +0000, Nick Alcock wrote:
> On 24 Feb 2023, Luis Chamberlain spake thusly:
> > Modules that are compiled in should succeed with a modprobe call as its
> > already loaded. The construct we're looking for is a way to detect
> > things which are built-in but *could* be modules. The annotation today
> > is done at build time for something built-in using a file path using
> > modinfo.
> >
> > All of the module macros which peg .modinfo section information for
> > built-in code can be extracted from vmlinux using objcopy -j .modinfo, and
> > that's exactly how modules.builtin.modinfo is built:
> >
> > objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
> >
> > From this we grep out the "file:" and sed it with a ^kernel prefix.
> > You can look at the commit 8b41fc4454e ("kbuild: create modules.builtin
> > without Makefile.modbuiltin or tristate.conf") which did that.
> >
> > If a module is built-in then MODULE_FILE() is used we and we add a
> > MODULE_INFO(file, KBUILD_MODFILE), and so the modinfo exists for the
> > "file:" tag for it. At build time we sed for all those with a kernel prefix
> > to build the modules.builtin file. That file is used by modprobe to tell
> > us "yes your module is loaded as its built-in".
> >
> > So the thing we wish to not have present is when built-in code is being
> > compiled but *cannot possibly* be module, and we have no way to verify that.
> >
> > So one way to go about this is to simply *not* use the MODULE_LICENSE()
> > which cannot possibly be modules so to simplfy the build process.
>
> I do wonder if I should drop this excellent description (up to the place
> where you start musing on alternatives) into the cover letters for the
> remaining two tranches in this series, to forestall further confusion.
> Any objection? (I doubt it, but it seems right to ask.)
Cover letters die, commit logs don't. So use it either as part of the
commit log or refer to this thread on the commit log. You can also try
to condense / paraphrase my description somehow too.
Luis
On 27 Feb 2023, Luis Chamberlain outgrape:
> Cover letters die, commit logs don't. So use it either as part of the
> commit log or refer to this thread on the commit log. You can also try
> to condense / paraphrase my description somehow too.
Hm. The commit logs have partly been pulled into other trees and are
thus to a degree set in stone. I can cite your post in the upcoming
pushes though, and in the -rc3 "whatever is left".
Thanks for the advice :)
--
NULL && (void)
On Sat, Feb 25, 2023 at 4:59 AM Luis Chamberlain <[email protected]> wrote:
>
> On Fri, Feb 24, 2023 at 05:35:34PM +0000, Marc Zyngier wrote:
> > On Fri, 24 Feb 2023 17:21:40 +0000,
> > Luis Chamberlain <[email protected]> wrote:
> > >
> > > On Fri, Feb 24, 2023 at 03:32:51PM +0000, Marc Zyngier wrote:
> > > > On Fri, 24 Feb 2023 15:07:53 +0000,
> > > > Nick Alcock <[email protected]> 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 <[email protected]>
> > > > > Suggested-by: Luis Chamberlain <[email protected]>
> > > > > Cc: Luis Chamberlain <[email protected]>
> > > > > Cc: [email protected]
> > > > > Cc: [email protected]
> > > > > Cc: Hitomi Hasegawa <[email protected]>
> > > > > Cc: Thomas Gleixner <[email protected]>
> > > > > Cc: Marc Zyngier <[email protected]>
> > > > > Cc: Philipp Zabel <[email protected]>
> > > > > ---
> > > > > drivers/irqchip/irq-renesas-rzg2l.c | 1 -
> > > > > 1 file changed, 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> > > > > index 25fd8ee66565..4bbfa2b0a4df 100644
> > > > > --- a/drivers/irqchip/irq-renesas-rzg2l.c
> > > > > +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> > > > > @@ -390,4 +390,3 @@ IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
> > > > > IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> > > > > MODULE_AUTHOR("Lad Prabhakar <[email protected]>");
> > > > > MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> > > > > -MODULE_LICENSE("GPL");
> > > >
> > > > I'm probably missing some context here, but I find it odd to drop
> > > > something that is a important piece of information because of what
> > > > looks like a tooling regression.
> > > >
> > > > It also means that once a random driver gets enabled as a module, it
> > > > won't load because it is now missing a MODULE_LICENSE() annotation.
> > > >
> > > > It feels like MODULE_LICENSE should instead degrade to an empty
> > > > statement when MODULE isn't defined. Why isn't this approach the
> > > > correct one?
> > > >
> > > > I expect the cover letter would have some pretty good information on
> > > > this, but lore.kernel.org doesn't seem to have it at the time I write
> > > > this ("Message-ID <[email protected]> not
> > > > found").
> > >
> > > The right thing is to not even have this and have the module license
> > > inferred from the SPDX tag. But for now we want to remove the tag from
> > > things we know for sure are not modules.
> >
> > I understand that you want to remove it. I don't get why this is the
> > right solution. Can you please assume that, in this particular
> > instance, I am a complete idiot and spell it out for me?
> >
> > Why isn't that a problem for modules that are compiled-in?
>
> Modules that are compiled in should succeed with a modprobe call as its
> already loaded. The construct we're looking for is a way to detect
> things which are built-in but *could* be modules. The annotation today
> is done at build time for something built-in using a file path using
> modinfo.
Why is it important to make "modprobe irq-renesas-rza1" fail?
With CONFIG_RENESAS_RZA1_IRQC=y, "modprobe irq-renesas-rza1"
exits with 0.
I do not think it is a big deal since irq-renesas-rza1
is available as built-in.
--
Best Regards
Masahiro Yamada