This is useful when using types that may or may not be empty in generic
code relying on these traits. It is also safe because technically a
no-op.

Reviewed-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 rust/kernel/transmute.rs | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
index be5dbf3829e2..5711580c9f9b 100644
--- a/rust/kernel/transmute.rs
+++ b/rust/kernel/transmute.rs
@@ -170,6 +170,10 @@ macro_rules! impl_frombytes {
 }
 
 impl_frombytes! {
+    // SAFETY: Inhabited ZSTs only have one possible bit pattern, and these two have no invariant.
+    (),
+    {<T>} core::marker::PhantomData<T>,
+
     // SAFETY: All bit patterns are acceptable values of the types below.
     u8, u16, u32, u64, usize,
     i8, i16, i32, i64, isize,
@@ -230,6 +234,10 @@ macro_rules! impl_asbytes {
 }
 
 impl_asbytes! {
+    // SAFETY: Inhabited ZSTs only have one possible bit pattern, and these two have no invariant.
+    (),
+    {<T>} core::marker::PhantomData<T>,
+
     // SAFETY: Instances of the following types have no uninitialized portions.
     u8, u16, u32, u64, usize,
     i8, i16, i32, i64, isize,

-- 
2.52.0

On Mon, 15 Dec 2025 14:49:09 +0900
Alexandre Courbot <acourbot@nvidia.com> wrote:

> This is useful when using types that may or may not be empty in generic
> code relying on these traits. It is also safe because technically a
> no-op.
> 
> Reviewed-by: Alistair Popple <apopple@nvidia.com>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
>  rust/kernel/transmute.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/rust/kernel/transmute.rs b/rust/kernel/transmute.rs
> index be5dbf3829e2..5711580c9f9b 100644
> --- a/rust/kernel/transmute.rs
> +++ b/rust/kernel/transmute.rs
> @@ -170,6 +170,10 @@ macro_rules! impl_frombytes {
>  }
>  
>  impl_frombytes! {
> +    // SAFETY: Inhabited ZSTs only have one possible bit pattern, and these two have no invariant.
> +    (),
> +    {<T>} core::marker::PhantomData<T>,
> +
>      // SAFETY: All bit patterns are acceptable values of the types below.
>      u8, u16, u32, u64, usize,
>      i8, i16, i32, i64, isize,
> @@ -230,6 +234,10 @@ macro_rules! impl_asbytes {
>  }
>  
>  impl_asbytes! {
> +    // SAFETY: Inhabited ZSTs only have one possible bit pattern, and these two have no invariant.

Some nit: technically you can turn any ZST into bytes, even those with
invariants or uninhabited. So while the comment is correct, it's kinda
redundant for the object -> bytes direction :)

No change required for this patch.

Best,
Gary

> +    (),
> +    {<T>} core::marker::PhantomData<T>,
> +
>      // SAFETY: Instances of the following types have no uninitialized portions.
>      u8, u16, u32, u64, usize,
>      i8, i16, i32, i64, isize,
>

On Mon Dec 15, 2025 at 6:49 AM CET, Alexandre Courbot wrote:
> This is useful when using types that may or may not be empty in generic
> code relying on these traits. It is also safe because technically a
> no-op.
>
> Reviewed-by: Alistair Popple <apopple@nvidia.com>
> Reviewed-by: Gary Guo <gary@garyguo.net>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

Reviewed-by: Benno Lossin <lossin@kernel.org>

Cheers,
Benno

> ---
>  rust/kernel/transmute.rs | 8 ++++++++
>  1 file changed, 8 insertions(+)

On Mon Dec 15, 2025 at 4:45 PM JST, Benno Lossin wrote:
> On Mon Dec 15, 2025 at 6:49 AM CET, Alexandre Courbot wrote:
>> This is useful when using types that may or may not be empty in generic
>> code relying on these traits. It is also safe because technically a
>> no-op.
>>
>> Reviewed-by: Alistair Popple <apopple@nvidia.com>
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Reviewed-by: Benno Lossin <lossin@kernel.org>

Miguel, are you ok if we take this one through the drm-rust tree? Nova
is likely to make use of it this cycle.

On Thu, Dec 18, 2025 at 2:32 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> Miguel, are you ok if we take this one through the drm-rust tree? Nova
> is likely to make use of it this cycle.

Sure:

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

(Catching up on emails...)

Cheers,
Miguel

On Thu Dec 25, 2025 at 5:53 PM JST, Miguel Ojeda wrote:
> On Thu, Dec 18, 2025 at 2:32 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> Miguel, are you ok if we take this one through the drm-rust tree? Nova
>> is likely to make use of it this cycle.
>
> Sure:
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>
> (Catching up on emails...)

Actually, the nova-core code that depends on this won't cut it this
cycle, so it is probably more appropriate to merge this through the Rust
tree.

Sorry for the back-and-forth and last minute notice!

On Fri, Jan 23, 2026 at 12:45 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>
> Actually, the nova-core code that depends on this won't cut it this
> cycle, so it is probably more appropriate to merge this through the Rust
> tree.
>
> Sorry for the back-and-forth and last minute notice!

No worries, I can do that -- do you want that I take the second patch too?

Cheers,
Miguel

On Sun Jan 25, 2026 at 1:17 AM JST, Miguel Ojeda wrote:
> On Fri, Jan 23, 2026 at 12:45 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> Actually, the nova-core code that depends on this won't cut it this
>> cycle, so it is probably more appropriate to merge this through the Rust
>> tree.
>>
>> Sorry for the back-and-forth and last minute notice!
>
> No worries, I can do that -- do you want that I take the second patch too?

If it doesn't conflict, that's probably a good idea yes!

Thanks,
Alex.

On Sat Jan 24, 2026 at 5:17 PM CET, Miguel Ojeda wrote:
> On Fri, Jan 23, 2026 at 12:45 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>> Actually, the nova-core code that depends on this won't cut it this
>> cycle, so it is probably more appropriate to merge this through the Rust
>> tree.
>>
>> Sorry for the back-and-forth and last minute notice!
>
> No worries, I can do that -- do you want that I take the second patch too?

There shouldn't be a conflict and it's always nice when a feature comes directly
with a user. :)