* [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules [not found] <20230302211759.30135-1-nick.alcock@oracle.com> @ 2023-03-02 21:17 ` Nick Alcock 2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock 1 sibling, 0 replies; 5+ messages in thread From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw) To: mcgrof Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Nishanth Menon, Tero Kristo, Santosh Shilimkar, Thomas Gleixner, Marc Zyngier, linux-arm-kernel 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: Nishanth Menon <nm@ti.com> Cc: Tero Kristo <kristo@kernel.org> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: linux-arm-kernel@lists.infradead.org --- drivers/irqchip/irq-ti-sci-inta.c | 1 - drivers/irqchip/irq-ti-sci-intr.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/irqchip/irq-ti-sci-inta.c b/drivers/irqchip/irq-ti-sci-inta.c index a6ecc53d055cd..7133f9fa6fd9e 100644 --- a/drivers/irqchip/irq-ti-sci-inta.c +++ b/drivers/irqchip/irq-ti-sci-inta.c @@ -743,4 +743,3 @@ module_platform_driver(ti_sci_inta_irq_domain_driver); MODULE_AUTHOR("Lokesh Vutla <lokeshvutla@ti.com>"); MODULE_DESCRIPTION("K3 Interrupt Aggregator driver over TI SCI protocol"); -MODULE_LICENSE("GPL v2"); diff --git a/drivers/irqchip/irq-ti-sci-intr.c b/drivers/irqchip/irq-ti-sci-intr.c index fe8fad22bcf96..939201b2c871a 100644 --- a/drivers/irqchip/irq-ti-sci-intr.c +++ b/drivers/irqchip/irq-ti-sci-intr.c @@ -302,4 +302,3 @@ module_platform_driver(ti_sci_intr_irq_domain_driver); MODULE_AUTHOR("Lokesh Vutla <lokeshvutla@ticom>"); MODULE_DESCRIPTION("K3 Interrupt Router driver over TI SCI protocol"); -MODULE_LICENSE("GPL v2"); -- 2.39.1.268.g9de2f9a303 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules [not found] <20230302211759.30135-1-nick.alcock@oracle.com> 2023-03-02 21:17 ` [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules Nick Alcock @ 2023-03-02 21:17 ` Nick Alcock 2023-03-03 0:31 ` Mark Brown 1 sibling, 1 reply; 5+ messages in thread From: Nick Alcock @ 2023-03-02 21:17 UTC (permalink / raw) To: mcgrof Cc: linux-modules, linux-kernel, Hitomi Hasegawa, Liam Girdwood, Mark Brown, Maxime Coquelin, Alexandre Torgue, linux-stm32, linux-arm-kernel 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: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org --- drivers/regulator/stm32-pwr.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/regulator/stm32-pwr.c b/drivers/regulator/stm32-pwr.c index 2a42acb7c24e9..8711afd60ade6 100644 --- a/drivers/regulator/stm32-pwr.c +++ b/drivers/regulator/stm32-pwr.c @@ -183,4 +183,3 @@ module_platform_driver(stm32_pwr_driver); MODULE_DESCRIPTION("STM32MP1 PWR voltage regulator driver"); MODULE_AUTHOR("Pascal Paillet <p.paillet@st.com>"); -MODULE_LICENSE("GPL v2"); -- 2.39.1.268.g9de2f9a303 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules 2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock @ 2023-03-03 0:31 ` Mark Brown 2023-03-03 18:30 ` Nick Alcock 0 siblings, 1 reply; 5+ messages in thread From: Mark Brown @ 2023-03-03 0:31 UTC (permalink / raw) To: Nick Alcock Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa, Liam Girdwood, Maxime Coquelin, Alexandre Torgue, linux-stm32, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 843 bytes --] On Thu, Mar 02, 2023 at 09:17:55PM +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 You've not copied me on the rest of the series so I'm not sure what's going on with dependencies. What's the story here? When sending a patch series it is important to ensure that all the various maintainers understand what the relationship between the patches as the expecation is that there will be interdependencies. Either copy everyone on the whole series or at least copy them on the cover letter and explain what's going on. If there are no strong interdependencies then it's generally simplest to just send the patches separately to avoid any possible confusion. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules 2023-03-03 0:31 ` Mark Brown @ 2023-03-03 18:30 ` Nick Alcock 2023-03-04 20:12 ` Mark Brown 0 siblings, 1 reply; 5+ messages in thread From: Nick Alcock @ 2023-03-03 18:30 UTC (permalink / raw) To: Mark Brown Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa, Liam Girdwood, Maxime Coquelin, Alexandre Torgue, linux-stm32, linux-arm-kernel On 3 Mar 2023, Mark Brown outgrape: > On Thu, Mar 02, 2023 at 09:17:55PM +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 > > You've not copied me on the rest of the series so I'm not sure > what's going on with dependencies. What's the story here? There are no interdependencies in this monster: it's just a pile of individual tiny machine-generated patches, all doing the exact same thing, and if and when they all make it in the invariant will finally hold that all modules shown as 'tristate' in Kconfig will have .modinfo in the resulting vmlinux when built in to the kernel, and modules.builtin will report them as built-in; and nothing which is *not* tristate will be reported in modules.builtin as a built-in module. That's it. (I don't expect them to all make it in in the first attempt, but I have a checker which I'll run to figure out which ones didn't make it in and try to deal with them, and run later at intervals to figure out if we regress and fix any regressions. The only likely type of regression is MODULE_LICENSE creeping into non-modules, because things that *can* be built as modules that don't have a MODULE_LICENSE cause more fallout and are spotted much faster.) (This is clearing the way for a later patch which will have interdependencies, but which is thankfully confined to a single subsystem so everyone else can ignore it. It happens to need accurate builtin module info at kallsyms-generation time, and this is the way Luis wants that done.) > When sending a patch series it is important to ensure that all > the various maintainers understand what the relationship between > the patches as the expecation is that there will be > interdependencies. Either copy everyone on the whole series or > at least copy them on the cover letter and explain what's going > on. If there are no strong interdependencies then it's generally > simplest to just send the patches separately to avoid any > possible confusion. The cover letter was sent to every related mailing list (or at least it was for patch series 2 and 5+: scripting problems blocked 3 and 4, sorry), which is what the LWN article on big patch series which I'm following recommended: <https://lwn.net/Articles/585782/>. I didn't want to spam actual maintainers with more info than that, since presumably they follow related-according-to-maintainer.pl lists anyway. As for copying everyone on a 121-patch monster like this... well, I think everyone would have wanted to throttle me, and I'm not sure they'd have been wrong. Originally I did this whole thing as one massive patch, but I was asked to split it up by subsystem. This yielded 121 tiny patches with distinct subsystems and Cc: sets. Sending a 121-patch series was my original plan but we talked to people first and they all said rough equivalents of 'god, no' and suggested splitting it up into a bunch of shorter mini-series to reduce the load on people's mailboxes and brains. I don't think anyone has previously suggested making it 121 individual patches with no cover letter whatsoever. As it is, those series that accidentally went out without cover letters properly Cc:ed confused some maintainers because of the lack of the cover letter. My apologies. It does seem this is an area where I can't please everyone. Some people don't want to be Cc:ed, others want everyone Cc:ed on all of them: some people want series, others want individual patches for everyone. I can't do both. Sorry about that. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules 2023-03-03 18:30 ` Nick Alcock @ 2023-03-04 20:12 ` Mark Brown 0 siblings, 0 replies; 5+ messages in thread From: Mark Brown @ 2023-03-04 20:12 UTC (permalink / raw) To: Nick Alcock Cc: mcgrof, linux-modules, linux-kernel, Hitomi Hasegawa, Liam Girdwood, Maxime Coquelin, Alexandre Torgue, linux-stm32, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 1885 bytes --] On Fri, Mar 03, 2023 at 06:30:02PM +0000, Nick Alcock wrote: > On 3 Mar 2023, Mark Brown outgrape: > > on. If there are no strong interdependencies then it's generally > > simplest to just send the patches separately to avoid any > > possible confusion. > The cover letter was sent to every related mailing list (or at least it > was for patch series 2 and 5+: scripting problems blocked 3 and 4, > sorry), which is what the LWN article on big patch series which I'm > following recommended: <https://lwn.net/Articles/585782/>. I didn't want > to spam actual maintainers with more info than that, since presumably > they follow related-according-to-maintainer.pl lists anyway. > As for copying everyone on a 121-patch monster like this... well, I > think everyone would have wanted to throttle me, and I'm not sure they'd > have been wrong. So given that there's no depenencies between the patches this seems like a good candidate for not sending as a series in the first place. > I don't think anyone has previously suggested making it 121 individual > patches with no cover letter whatsoever. As it is, those series that > accidentally went out without cover letters properly Cc:ed confused some > maintainers because of the lack of the cover letter. My apologies. It's really quite common for people to just send lots of individual patches when there's no interdependencies - a lot of the generated cleanups do that. > It does seem this is an area where I can't please everyone. Some people > don't want to be Cc:ed, others want everyone Cc:ed on all of them: some > people want series, others want individual patches for everyone. I can't > do both. Sorry about that. The important thing isn't so much the specific thing as making it clear what's going on - if you send a series with no information about the how the series should be handled it's unclear what's going on. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-03-04 20:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230302211759.30135-1-nick.alcock@oracle.com>
2023-03-02 21:17 ` [PATCH 01/17] irqchip: remove MODULE_LICENSE in non-modules Nick Alcock
2023-03-02 21:17 ` [PATCH 13/17] regulator: stm32-pwr: " Nick Alcock
2023-03-03 0:31 ` Mark Brown
2023-03-03 18:30 ` Nick Alcock
2023-03-04 20:12 ` Mark Brown
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).