Kernel modules that use C symbols exported via `EXPORT_SYMBOL_NS` must
declare this dependency for `modpost` verification. C modules achieve
this by using the `MODULE_IMPORT_NS(NAMESPACE)` macro, which embeds an
`import_ns=<NAMESPACE>` tag into the `.modinfo` section.

The Rust `module!` macro lacked the ability to generate these tags,
resulting in build warnings for Rust drivers (like the PWM driver) that
call namespaced C functions.

Modify the `module!` macro's internal parser (`ModuleInfo`) to accept a
new optional field `imports_ns`, which takes an array of namespace
strings.  Update the code generator (`ModInfoBuilder::emit`) loop to
iterate over these strings and emit the corresponding
`import_ns=<NAMESPACE>` tags into the `.modinfo` section using the
existing `#[link_section]` mechanism.

This provides the necessary infrastructure for Rust modules to correctly
declare their C namespace dependencies.

Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
---
 rust/macros/module.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -98,6 +98,7 @@ struct ModuleInfo {
     description: Option<String>,
     alias: Option<Vec<String>>,
     firmware: Option<Vec<String>>,
+    imports_ns: Option<Vec<String>>,
 }
 
 impl ModuleInfo {
@@ -112,6 +113,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
             "license",
             "alias",
             "firmware",
+            "imports_ns",
         ];
         const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
         let mut seen_keys = Vec::new();
@@ -137,6 +139,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
                 "license" => info.license = expect_string_ascii(it),
                 "alias" => info.alias = Some(expect_string_array(it)),
                 "firmware" => info.firmware = Some(expect_string_array(it)),
+                "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
                 _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
             }
 
@@ -195,6 +198,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
             modinfo.emit("firmware", &fw);
         }
     }
+    if let Some(imports) = info.imports_ns {
+        for ns in imports {
+            modinfo.emit("import_ns", &ns);
+        }
+    }
 
     // Built-in modules also export the `file` modinfo string.
     let file =

-- 
2.34.1

Hello,

I already asked this in reply to the cover letter, but the question was
lost on the way (no offense!), so I'm asking again. As it only really
affects this patch, I'm doing that here:

On Tue, Oct 28, 2025 at 01:22:32PM +0100, Michal Wilczynski wrote:
> Kernel modules that use C symbols exported via `EXPORT_SYMBOL_NS` must
> declare this dependency for `modpost` verification. C modules achieve
> this by using the `MODULE_IMPORT_NS(NAMESPACE)` macro, which embeds an
> `import_ns=<NAMESPACE>` tag into the `.modinfo` section.
> 
> The Rust `module!` macro lacked the ability to generate these tags,
> resulting in build warnings for Rust drivers (like the PWM driver) that
> call namespaced C functions.
> 
> Modify the `module!` macro's internal parser (`ModuleInfo`) to accept a
> new optional field `imports_ns`, which takes an array of namespace
> strings.  Update the code generator (`ModInfoBuilder::emit`) loop to
> iterate over these strings and emit the corresponding
> `import_ns=<NAMESPACE>` tags into the `.modinfo` section using the
> existing `#[link_section]` mechanism.
> 
> This provides the necessary infrastructure for Rust modules to correctly
> declare their C namespace dependencies.
> 
> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
> ---
>  rust/macros/module.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)

Can I have some blessing to take this patch via my pwm tree? Would you
prefer a tag to also merge it into your tree? Then I would apply it on
top of 6.18-rc1 and provide a tag for you to merge.

Best regards
Uwe

On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>
> I already asked this in reply to the cover letter, but the question was
> lost on the way (no offense!), so I'm asking again. As it only really
> affects this patch, I'm doing that here:
>
> Can I have some blessing to take this patch via my pwm tree? Would you
> prefer a tag to also merge it into your tree? Then I would apply it on
> top of 6.18-rc1 and provide a tag for you to merge.

Sounds fine to me, but I am Cc'ing the modules maintainers since they
were not, just in case:

Acked-by: Miguel Ojeda <ojeda@kernel.org>

I think we don't need the tag/merge, unless someone else is looking to
use this (is there such a user? I may have missed it).

Thanks!

Cheers,
Miguel

On 31/10/2025 13.57, Miguel Ojeda wrote:
> On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>>
>> I already asked this in reply to the cover letter, but the question was
>> lost on the way (no offense!), so I'm asking again. As it only really
>> affects this patch, I'm doing that here:
>>
>> Can I have some blessing to take this patch via my pwm tree? Would you
>> prefer a tag to also merge it into your tree? Then I would apply it on
>> top of 6.18-rc1 and provide a tag for you to merge.
> 
> Sounds fine to me, but I am Cc'ing the modules maintainers since they
> were not, just in case:
> 
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> 
> I think we don't need the tag/merge, unless someone else is looking to
> use this (is there such a user? I may have missed it).
> 
> Thanks!
> 
> Cheers,
> Miguel

Uwe, that's okay from modules side:

Acked-by: Daniel Gomez <da.gomez@samsung.com>

FYI, I haven't merged Andreas's patches (rust: extend `module!` macro with
integer parameter support) yet, which add rust/macros/module.rs to our
MAINTAINERS file list. So, it's fine from modules side to go through your tree.
I was aiming to merge these patches along with some others for this week but
I've found a regression in kmod testing introduced in the latest v6.18-rc1,
which is taking me some extra time.

Hello Daniel, hello Miguel,

On Fri, Oct 31, 2025 at 02:12:29PM +0100, Daniel Gomez wrote:
> On 31/10/2025 13.57, Miguel Ojeda wrote:
> > On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
> > > Can I have some blessing to take this patch via my pwm tree? Would you
> > > prefer a tag to also merge it into your tree? Then I would apply it on
> > > top of 6.18-rc1 and provide a tag for you to merge.
> > 
> > Sounds fine to me, but I am Cc'ing the modules maintainers since they
> > were not, just in case:

Good idea, thanks for catching that.

> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
> > [...]
> 
> Uwe, that's okay from modules side:
> 
> Acked-by: Daniel Gomez <da.gomez@samsung.com>

Thanks for your Acks, I applied patches #1-#3 to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next
(#4 was applied already).
 
> FYI, I haven't merged Andreas's patches (rust: extend `module!` macro with
> integer parameter support) yet, which add rust/macros/module.rs to our
> MAINTAINERS file list. So, it's fine from modules side to go through your tree.
> I was aiming to merge these patches along with some others for this week but
> I've found a regression in kmod testing introduced in the latest v6.18-rc1,
> which is taking me some extra time.

If the issues you mentioned are sorted out and you apply patches that
conflict with the changes I committed, please get in touch that we
coordinate if/how to sort them out.

Also if the need for a tag to share the commit arises, please coordinate
and don't just merge the just now created commits, as I like to be able
to rewrite my tree for late Acks etc. So I'd like to prepare and know
when commits become set in stone.

Best regards
Uwe

On Tue, Oct 28, 2025 at 01:22:32PM +0100, Michal Wilczynski wrote:
> Kernel modules that use C symbols exported via `EXPORT_SYMBOL_NS` must
> declare this dependency for `modpost` verification. C modules achieve
> this by using the `MODULE_IMPORT_NS(NAMESPACE)` macro, which embeds an
> `import_ns=<NAMESPACE>` tag into the `.modinfo` section.
> 
> The Rust `module!` macro lacked the ability to generate these tags,
> resulting in build warnings for Rust drivers (like the PWM driver) that
> call namespaced C functions.
> 
> Modify the `module!` macro's internal parser (`ModuleInfo`) to accept a
> new optional field `imports_ns`, which takes an array of namespace
> strings.  Update the code generator (`ModInfoBuilder::emit`) loop to
> iterate over these strings and emit the corresponding
> `import_ns=<NAMESPACE>` tags into the `.modinfo` section using the
> existing `#[link_section]` mechanism.
> 
> This provides the necessary infrastructure for Rust modules to correctly
> declare their C namespace dependencies.
> 
> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

On Tue, Oct 28, 2025 at 01:22:32PM +0100, Michal Wilczynski wrote:
> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
> ---

Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>