* [PATCH v2] rust: add 'firmware' field support to module! macro
@ 2024-05-01 12:35 FUJITA Tomonori
2024-05-07 23:11 ` FUJITA Tomonori
2024-07-09 7:33 ` Miguel Ojeda
0 siblings, 2 replies; 10+ messages in thread
From: FUJITA Tomonori @ 2024-05-01 12:35 UTC (permalink / raw)
To: rust-for-linux; +Cc: miguel.ojeda.sandonis, benno.lossin
This adds 'firmware' field support to module! macro, corresponds to
MODULE_FIRMWARE macro. You can specify the file names of binary
firmware that the kernel module requires. The information is embedded
in the modinfo section of the kernel module. For example, a tool to
build an initramfs uses this information to put the firmware files
into the initramfs image.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
---
rust/macros/lib.rs | 32 ++++++++++++++++++++++++++++++++
rust/macros/module.rs | 18 ++++++++++++++++--
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index f489f3157383..6420ebc22219 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -67,6 +67,36 @@
/// }
/// ```
///
+/// ## Firmware
+///
+/// The following example shows how to declare a kernel module that needs
+/// to load binary firmware files. You need to specify the file names of
+/// the firmware in the `firmware` field. The information is embedded
+/// in the `modinfo` section of the kernel module. For example, a tool to
+/// build an initramfs uses this information to put the firmware files into
+/// the initramfs image.
+///
+/// ```ignore
+/// use kernel::prelude::*;
+///
+/// module!{
+/// type: MyDeviceDriverModule,
+/// name: "my_device_driver_module",
+/// author: "Rust for Linux Contributors",
+/// description: "My device driver requires firmware",
+/// license: "GPL",
+/// firmware: ["my_device_firmware1.bin", "my_device_firmware2.bin"],
+/// }
+///
+/// struct MyDeviceDriverModule;
+///
+/// impl kernel::Module for MyDeviceDriverModule {
+/// fn init() -> Result<Self> {
+/// Ok(Self)
+/// }
+/// }
+/// ```
+///
/// # Supported argument types
/// - `type`: type which implements the [`Module`] trait (required).
/// - `name`: byte array of the name of the kernel module (required).
@@ -74,6 +104,8 @@
/// - `description`: byte array of the description of the kernel module.
/// - `license`: byte array of the license of the kernel module (required).
/// - `alias`: byte array of alias name of the kernel module.
+/// - `firmware`: array of ASCII string literals of the firmware files of
+/// the kernel module.
#[proc_macro]
pub fn module(ts: TokenStream) -> TokenStream {
module::module(ts)
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index 27979e582e4b..5fdaac17a733 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -97,14 +97,22 @@ struct ModuleInfo {
author: Option<String>,
description: Option<String>,
alias: Option<Vec<String>>,
+ firmware: Option<Vec<String>>,
}
impl ModuleInfo {
fn parse(it: &mut token_stream::IntoIter) -> Self {
let mut info = ModuleInfo::default();
- const EXPECTED_KEYS: &[&str] =
- &["type", "name", "author", "description", "license", "alias"];
+ const EXPECTED_KEYS: &[&str] = &[
+ "type",
+ "name",
+ "author",
+ "description",
+ "license",
+ "alias",
+ "firmware",
+ ];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@ -131,6 +139,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"description" => info.description = Some(expect_string(it)),
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
+ "firmware" => info.firmware = Some(expect_string_array(it)),
_ => panic!(
"Unknown key \"{}\". Valid keys are: {:?}.",
key, EXPECTED_KEYS
@@ -186,6 +195,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
modinfo.emit("alias", &alias);
}
}
+ if let Some(firmware) = info.firmware {
+ for fw in firmware {
+ modinfo.emit("firmware", &fw);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-05-01 12:35 [PATCH v2] rust: add 'firmware' field support to module! macro FUJITA Tomonori
@ 2024-05-07 23:11 ` FUJITA Tomonori
2024-05-08 14:46 ` Miguel Ojeda
2024-07-09 7:33 ` Miguel Ojeda
1 sibling, 1 reply; 10+ messages in thread
From: FUJITA Tomonori @ 2024-05-07 23:11 UTC (permalink / raw)
To: miguel.ojeda.sandonis; +Cc: rust-for-linux, benno.lossin
Hi,
On Wed, 1 May 2024 21:35:48 +0900
FUJITA Tomonori <fujita.tomonori@gmail.com> wrote:
> This adds 'firmware' field support to module! macro, corresponds to
> MODULE_FIRMWARE macro. You can specify the file names of binary
> firmware that the kernel module requires. The information is embedded
> in the modinfo section of the kernel module. For example, a tool to
> build an initramfs uses this information to put the firmware files
> into the initramfs image.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
> Reviewed-by: Benno Lossin <benno.lossin@proton.me>
> ---
> rust/macros/lib.rs | 32 ++++++++++++++++++++++++++++++++
> rust/macros/module.rs | 18 ++++++++++++++++--
> 2 files changed, 48 insertions(+), 2 deletions(-)
Miguel, can you apply this to rust-next? Or you want to change
something?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-05-07 23:11 ` FUJITA Tomonori
@ 2024-05-08 14:46 ` Miguel Ojeda
2024-05-08 23:58 ` FUJITA Tomonori
0 siblings, 1 reply; 10+ messages in thread
From: Miguel Ojeda @ 2024-05-08 14:46 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: rust-for-linux, benno.lossin
On Wed, May 8, 2024 at 1:11 AM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> Miguel, can you apply this to rust-next? Or you want to change
> something?
I typically apply things that were sent up to (roughly) -rc5 [1], but
exceptions can happen of course (e.g. a fix).
Do you need this to go in this cycle for some reason? If it is so that
you can send QT2025 next cycle, we can figure it out so that you don't
need to wait one extra cycle just for this.
This would also allow us to get the cleanup to the other "Supported
argument types" together with this one.
[1] https://rust-for-linux.com/contributing#key-cycle-dates
Cheers,
Miguel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-05-08 14:46 ` Miguel Ojeda
@ 2024-05-08 23:58 ` FUJITA Tomonori
2024-05-12 16:53 ` Miguel Ojeda
0 siblings, 1 reply; 10+ messages in thread
From: FUJITA Tomonori @ 2024-05-08 23:58 UTC (permalink / raw)
To: miguel.ojeda.sandonis; +Cc: fujita.tomonori, rust-for-linux, benno.lossin
Hi,
On Wed, 8 May 2024 16:46:49 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Wed, May 8, 2024 at 1:11 AM FUJITA Tomonori
> <fujita.tomonori@gmail.com> wrote:
>>
>> Miguel, can you apply this to rust-next? Or you want to change
>> something?
>
> I typically apply things that were sent up to (roughly) -rc5 [1], but
> exceptions can happen of course (e.g. a fix).
Thanks, I didn't know this.
> Do you need this to go in this cycle for some reason? If it is so that
> you can send QT2025 next cycle, we can figure it out so that you don't
> need to wait one extra cycle just for this.
I'll try to push QT2025 for 6.11 via netdev tree. So I hope features
which QT2025 needs to be merged for 6.10, especially a feature that
would be conflicted in rust and netdev trees.
> This would also allow us to get the cleanup to the other "Supported
> argument types" together with this one.
That's exactly why I hope that this patch is merged for 6.10, as I
wrote above. The cleanup will be merged via rust tree. It makes
complicated to put this patch into QT2025 patchset for netdev tree.
But I don't think that this patch is an exception to the -rc5 rule. So
please push this patch for 6.11. I'll think about a way to push
QT2025.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-05-08 23:58 ` FUJITA Tomonori
@ 2024-05-12 16:53 ` Miguel Ojeda
2024-07-05 14:22 ` Miguel Ojeda
0 siblings, 1 reply; 10+ messages in thread
From: Miguel Ojeda @ 2024-05-12 16:53 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: rust-for-linux, benno.lossin
On Thu, May 9, 2024 at 1:58 AM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> I'll try to push QT2025 for 6.11 via netdev tree. So I hope features
> which QT2025 needs to be merged for 6.10, especially a feature that
> would be conflicted in rust and netdev trees.
>
> That's exactly why I hope that this patch is merged for 6.10, as I
> wrote above. The cleanup will be merged via rust tree. It makes
> complicated to put this patch into QT2025 patchset for netdev tree.
>
> But I don't think that this patch is an exception to the -rc5 rule. So
> please push this patch for 6.11. I'll think about a way to push
> QT2025.
Thanks for confirming. If netdev wants to apply QT2025 for 6.11, they
could perhaps carry this patch with our Acked-by -- it seems simple
enough. Another option is creating a branch and merge it in both trees
if needed.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-05-12 16:53 ` Miguel Ojeda
@ 2024-07-05 14:22 ` Miguel Ojeda
2024-07-05 14:44 ` FUJITA Tomonori
0 siblings, 1 reply; 10+ messages in thread
From: Miguel Ojeda @ 2024-07-05 14:22 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: rust-for-linux, benno.lossin
On Sun, May 12, 2024 at 6:53 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Thanks for confirming. If netdev wants to apply QT2025 for 6.11, they
> could perhaps carry this patch with our Acked-by -- it seems simple
> enough. Another option is creating a branch and merge it in both trees
> if needed.
Tomonori: Any update on this? Will they take it?
Thanks!
Cheers,
Miguel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-07-05 14:22 ` Miguel Ojeda
@ 2024-07-05 14:44 ` FUJITA Tomonori
2024-07-05 14:57 ` Miguel Ojeda
0 siblings, 1 reply; 10+ messages in thread
From: FUJITA Tomonori @ 2024-07-05 14:44 UTC (permalink / raw)
To: miguel.ojeda.sandonis; +Cc: fujita.tomonori, rust-for-linux, benno.lossin
On Fri, 5 Jul 2024 16:22:23 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Sun, May 12, 2024 at 6:53 PM Miguel Ojeda
> <miguel.ojeda.sandonis@gmail.com> wrote:
>>
>> Thanks for confirming. If netdev wants to apply QT2025 for 6.11, they
>> could perhaps carry this patch with our Acked-by -- it seems simple
>> enough. Another option is creating a branch and merge it in both trees
>> if needed.
>
> Tomonori: Any update on this? Will they take it?
Please merge this patch via rust tree for 6.11-rc1.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-07-05 14:44 ` FUJITA Tomonori
@ 2024-07-05 14:57 ` Miguel Ojeda
2024-07-05 15:06 ` FUJITA Tomonori
0 siblings, 1 reply; 10+ messages in thread
From: Miguel Ojeda @ 2024-07-05 14:57 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: rust-for-linux, benno.lossin
On Fri, Jul 5, 2024 at 4:44 PM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> Please merge this patch via rust tree for 6.11-rc1.
Thanks for the quick reply!
Then I assume they will not take anything depending on this one this
cycle then, i.e. I will not create a branch.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-07-05 14:57 ` Miguel Ojeda
@ 2024-07-05 15:06 ` FUJITA Tomonori
0 siblings, 0 replies; 10+ messages in thread
From: FUJITA Tomonori @ 2024-07-05 15:06 UTC (permalink / raw)
To: miguel.ojeda.sandonis; +Cc: fujita.tomonori, rust-for-linux, benno.lossin
On Fri, 5 Jul 2024 16:57:55 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> On Fri, Jul 5, 2024 at 4:44 PM FUJITA Tomonori
> <fujita.tomonori@gmail.com> wrote:
>>
>> Please merge this patch via rust tree for 6.11-rc1.
>
> Thanks for the quick reply!
>
> Then I assume they will not take anything depending on this one this
> cycle then, i.e. I will not create a branch.
Yes, nothing depending on this patch will be merged via netdev for
6.11-rc1. So you can simply merge this via rust tree without any extra
care.
Thanks!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] rust: add 'firmware' field support to module! macro
2024-05-01 12:35 [PATCH v2] rust: add 'firmware' field support to module! macro FUJITA Tomonori
2024-05-07 23:11 ` FUJITA Tomonori
@ 2024-07-09 7:33 ` Miguel Ojeda
1 sibling, 0 replies; 10+ messages in thread
From: Miguel Ojeda @ 2024-07-09 7:33 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: rust-for-linux, benno.lossin
On Wed, May 1, 2024 at 2:38 PM FUJITA Tomonori
<fujita.tomonori@gmail.com> wrote:
>
> This adds 'firmware' field support to module! macro, corresponds to
> MODULE_FIRMWARE macro. You can specify the file names of binary
> firmware that the kernel module requires. The information is embedded
> in the modinfo section of the kernel module. For example, a tool to
> build an initramfs uses this information to put the firmware files
> into the initramfs image.
>
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
> Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Applied series to `rust-next` (on top of Aswin's since that looked a
bit better rather than the other way around) -- thanks everyone!
Cheers,
Miguel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-07-09 7:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-01 12:35 [PATCH v2] rust: add 'firmware' field support to module! macro FUJITA Tomonori
2024-05-07 23:11 ` FUJITA Tomonori
2024-05-08 14:46 ` Miguel Ojeda
2024-05-08 23:58 ` FUJITA Tomonori
2024-05-12 16:53 ` Miguel Ojeda
2024-07-05 14:22 ` Miguel Ojeda
2024-07-05 14:44 ` FUJITA Tomonori
2024-07-05 14:57 ` Miguel Ojeda
2024-07-05 15:06 ` FUJITA Tomonori
2024-07-09 7:33 ` Miguel Ojeda
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).