drivers/pwm/pwm_th1520.rs | 4 ++-- rust/kernel/pwm.rs | 23 +++++++++++++++++++++++ rust/macros/module.rs | 8 ++++++++ 3 files changed, 33 insertions(+), 2 deletions(-)
This series addresses build warnings reported by `modpost` for the Rust
PWM driver (`pwm_th1520`) in linux-next:
WARNING: modpost: module pwm_th1520 uses symbol pwmchip_release from
namespace PWM, but does not import it.
These warnings occur because Rust modules, like C modules, need to
declare their dependencies on C symbols exported to specific namespaces
(using `EXPORT_SYMBOL_NS` in C). This is done by embedding
"import_ns=<NAMESPACE>" tags into the module's `.modinfo` section, which
`modpost` verifies. The C macro `MODULE_IMPORT_NS()` handles this, but
the Rust `module!` macro lacked equivalent functionality.
This series introduces the necessary support:
Patch 1 extends the core `module!` macro in `rust/macros/module.rs`
to parse an optional `imports_ns: [...]` field and generate the required
`import_ns` tags in the `.modinfo` section.
Patch 2 adds a convenience macro `module_pwm_platform_driver!` to
`rust/kernel/pwm.rs`. This macro wraps the standard
`module_platform_driver!` and automatically adds `imports_ns: ["PWM"]`,
simplifying module declaration for PWM driver authors.
Patch 3 updates the `pwm_th1520` driver to use the new helper macro,
fixing the build warnings.
Patch 4 includes a minor clippy style fix for the `pwm_th1520` driver.
Thanks to Stephen Rothwell for reporting the build warnings.
---
Michal Wilczynski (4):
rust: macros: Add support for 'imports_ns' to module!
rust: pwm: Add module_pwm_platform_driver! macro
pwm: th1520: Use module_pwm_platform_driver! macro
pwm: th1520: Fix clippy warning for redundant struct field init
drivers/pwm/pwm_th1520.rs | 4 ++--
rust/kernel/pwm.rs | 23 +++++++++++++++++++++++
rust/macros/module.rs | 8 ++++++++
3 files changed, 33 insertions(+), 2 deletions(-)
---
base-commit: cb6649f6217c0331b885cf787f1d175963e2a1d2
change-id: 20251028-pwm_fixes-cca9db267458
prerequisite-message-id: 20251016-rust-next-pwm-working-fan-for-sending-v16-0-a5df2405d2bd@samsung.com
prerequisite-patch-id: bddf445f74431c647c134eabb3eb029374455a2e
prerequisite-patch-id: 6fbf1d04b8ca1c72362d7f3a4e420be8f95a44a8
prerequisite-patch-id: d4adae5b56cd13089bfa070bc4bd3bbc6f50b097
prerequisite-patch-id: c1a631eb7a5d8f1d8dfdae847e8b32e8d5ea95d8
prerequisite-patch-id: 6c2a0d316d9d0aa99346cb12afe4b9dc5ac217db
prerequisite-patch-id: 4a05412207606f8df51db0068c4f57785b02a271
prerequisite-patch-id: e0a0d54562e883b07cbe9c5b3721687de5b4ea55
Best regards,
--
Michal Wilczynski <m.wilczynski@samsung.com>
Hello, On Tue, Oct 28, 2025 at 01:22:31PM +0100, Michal Wilczynski wrote: > This series addresses build warnings reported by `modpost` for the Rust > PWM driver (`pwm_th1520`) in linux-next: > > WARNING: modpost: module pwm_th1520 uses symbol pwmchip_release from > namespace PWM, but does not import it. > > These warnings occur because Rust modules, like C modules, need to > declare their dependencies on C symbols exported to specific namespaces > (using `EXPORT_SYMBOL_NS` in C). This is done by embedding > "import_ns=<NAMESPACE>" tags into the module's `.modinfo` section, which > `modpost` verifies. The C macro `MODULE_IMPORT_NS()` handles this, but > the Rust `module!` macro lacked equivalent functionality. > > This series introduces the necessary support: > > Patch 1 extends the core `module!` macro in `rust/macros/module.rs` > to parse an optional `imports_ns: [...]` field and generate the required > `import_ns` tags in the `.modinfo` section. > > Patch 2 adds a convenience macro `module_pwm_platform_driver!` to > `rust/kernel/pwm.rs`. This macro wraps the standard > `module_platform_driver!` and automatically adds `imports_ns: ["PWM"]`, > simplifying module declaration for PWM driver authors. > > Patch 3 updates the `pwm_th1520` driver to use the new helper macro, > fixing the build warnings. Given that for now the pwm_th1520 driver is the only user, does it make sense to merge this series via my pwm tree? If it goes via a different tree, I'd like to have a tag to merge into my tree to hand over code which is free of warnings to Linus in the next merge window. > Patch 4 includes a minor clippy style fix for the `pwm_th1520` driver. If you could mention the command that makes this warning visible, I'd be glad to add that to my repertoire of build checks. Thanks for addressing the issue Uwe
On Wed, Oct 29, 2025 at 11:04 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>
> If you could mention the command that makes this warning visible, I'd be
> glad to add that to my repertoire of build checks.
Yeah, please do!
I do my best to keep even linux-next and stable kernels Clippy clean
as much as possible, so it would be nice to have that Clippy fix added
to -next soon.
I have other steps that maintainers/contributors should run here:
https://rust-for-linux.com/contributing#submit-checklist-addendum
Essentially / most importantly: `rustfmt`, `rustdoc` and `CLIPPY=1`.
I am sending a couple fixes for those.
Thanks!
Cheers,
Miguel
On 10/29/25 19:18, Miguel Ojeda wrote: > On Wed, Oct 29, 2025 at 11:04 AM Uwe Kleine-König <ukleinek@kernel.org> wrote: >> >> If you could mention the command that makes this warning visible, I'd be >> glad to add that to my repertoire of build checks. > > Yeah, please do! > > I do my best to keep even linux-next and stable kernels Clippy clean > as much as possible, so it would be nice to have that Clippy fix added > to -next soon. > > I have other steps that maintainers/contributors should run here: > > https://protect2.fireeye.com/v1/url?k=0d35e0d3-6dd77d8e-0d346b9c-000babd9f1ba-e5d27bbbccd997ca&q=1&e=d4a64c99-aab6-4741-9747-63f10e63aed4&u=https%3A%2F%2Frust-for-linux.com%2Fcontributing%23submit-checklist-addendum > > Essentially / most importantly: `rustfmt`, `rustdoc` and `CLIPPY=1`. Oh yeah I think I remembered to run 'rustfmt' couple months ago, but over time when sending revisions forgot about that, sorry. I guess it would be great to extend 'b4 prep --check' for those checks as well. > > I am sending a couple fixes for those. > > Thanks! > > Cheers, > Miguel > Best regards, -- Michal Wilczynski <m.wilczynski@samsung.com>
On 10/29/25 11:04, Uwe Kleine-König wrote: > Hello, > > On Tue, Oct 28, 2025 at 01:22:31PM +0100, Michal Wilczynski wrote: >> This series addresses build warnings reported by `modpost` for the Rust >> PWM driver (`pwm_th1520`) in linux-next: >> >> WARNING: modpost: module pwm_th1520 uses symbol pwmchip_release from >> namespace PWM, but does not import it. >> >> These warnings occur because Rust modules, like C modules, need to >> declare their dependencies on C symbols exported to specific namespaces >> (using `EXPORT_SYMBOL_NS` in C). This is done by embedding >> "import_ns=<NAMESPACE>" tags into the module's `.modinfo` section, which >> `modpost` verifies. The C macro `MODULE_IMPORT_NS()` handles this, but >> the Rust `module!` macro lacked equivalent functionality. >> >> This series introduces the necessary support: >> >> Patch 1 extends the core `module!` macro in `rust/macros/module.rs` >> to parse an optional `imports_ns: [...]` field and generate the required >> `import_ns` tags in the `.modinfo` section. >> >> Patch 2 adds a convenience macro `module_pwm_platform_driver!` to >> `rust/kernel/pwm.rs`. This macro wraps the standard >> `module_platform_driver!` and automatically adds `imports_ns: ["PWM"]`, >> simplifying module declaration for PWM driver authors. >> >> Patch 3 updates the `pwm_th1520` driver to use the new helper macro, >> fixing the build warnings. > > Given that for now the pwm_th1520 driver is the only user, does it make > sense to merge this series via my pwm tree? If it goes via a different > tree, I'd like to have a tag to merge into my tree to hand over code > which is free of warnings to Linus in the next merge window. Hi, I agree with you. Hopefully we can get an ack from the Rust maintainers and the series can go through your tree. > >> Patch 4 includes a minor clippy style fix for the `pwm_th1520` driver. > > If you could mention the command that makes this warning visible, I'd be > glad to add that to my repertoire of build checks. I'm using the following command to compile the kernel: $ make ARCH=riscv -j20 LLVM=1 CLIPPY=1 I guess you were missing the 'CLIPPY=1' part. > > Thanks for addressing the issue > Uwe Best regards, -- Michal Wilczynski <m.wilczynski@samsung.com>
© 2016 - 2026 Red Hat, Inc.