drivers/gpu/drm/nova/file.rs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
In 32-bit arm, the build fails with:
error[E0308]: mismatched types
--> drivers/gpu/drm/nova/file.rs:42:28
|
42 | getparam.set_value(value);
| --------- ^^^^^ expected `u64`, found `u32`
| |
| arguments to this method are incorrect
|
note: method defined here
--> drivers/gpu/drm/nova/uapi.rs:29:12
|
29 | pub fn set_value(&self, v: u64) {
| ^^^^^^^^^ ------
help: you can convert a `u32` to a `u64`
|
42 | getparam.set_value(value.into());
| +++++++
The reason is that `Getparam::set_value` takes a `u64` (from the UAPI),
but `pci::Device::resource_len()` returns a `resource_size_t`, which is a
`phys_addr_t`, which may be 32- or 64-bit.
Thus add an `into()` call to support the 32-bit case, while allowing the
Clippy lint that complains in the 64-bit case where the type is the same.
Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
As discussed, it may be best to have a newtype, or at least a function
to perform this -- here it is the minimal fix nevertheless.
drivers/gpu/drm/nova/file.rs | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nova/file.rs b/drivers/gpu/drm/nova/file.rs
index 7e59a34b830d..4fe62cf98a23 100644
--- a/drivers/gpu/drm/nova/file.rs
+++ b/drivers/gpu/drm/nova/file.rs
@@ -39,7 +39,8 @@ pub(crate) fn get_param(
_ => return Err(EINVAL),
};
- getparam.set_value(value);
+ #[allow(clippy::useless_conversion)]
+ getparam.set_value(value.into());
Ok(0)
}
base-commit: 89be9a83ccf1f88522317ce02f854f30d6115c41
--
2.50.1On 7/24/25 6:54 PM, Miguel Ojeda wrote:
> In 32-bit arm, the build fails with:
>
> error[E0308]: mismatched types
> --> drivers/gpu/drm/nova/file.rs:42:28
> |
> 42 | getparam.set_value(value);
> | --------- ^^^^^ expected `u64`, found `u32`
> | |
> | arguments to this method are incorrect
> |
> note: method defined here
> --> drivers/gpu/drm/nova/uapi.rs:29:12
> |
> 29 | pub fn set_value(&self, v: u64) {
> | ^^^^^^^^^ ------
> help: you can convert a `u32` to a `u64`
> |
> 42 | getparam.set_value(value.into());
> | +++++++
>
> The reason is that `Getparam::set_value` takes a `u64` (from the UAPI),
> but `pci::Device::resource_len()` returns a `resource_size_t`, which is a
> `phys_addr_t`, which may be 32- or 64-bit.
>
> Thus add an `into()` call to support the 32-bit case, while allowing the
> Clippy lint that complains in the 64-bit case where the type is the same.
>
> Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Applied to drm-misc-fixes, thanks!
Hi Miguel,
On 24.07.25 6:54 PM, Miguel Ojeda wrote:
> In 32-bit arm, the build fails with:
>
> error[E0308]: mismatched types
> --> drivers/gpu/drm/nova/file.rs:42:28
> |
> 42 | getparam.set_value(value);
> | --------- ^^^^^ expected `u64`, found `u32`
> | |
> | arguments to this method are incorrect
> |
> note: method defined here
> --> drivers/gpu/drm/nova/uapi.rs:29:12
> |
> 29 | pub fn set_value(&self, v: u64) {
> | ^^^^^^^^^ ------
> help: you can convert a `u32` to a `u64`
> |
> 42 | getparam.set_value(value.into());
> | +++++++
>
> The reason is that `Getparam::set_value` takes a `u64` (from the UAPI),
> but `pci::Device::resource_len()` returns a `resource_size_t`, which is a
> `phys_addr_t`, which may be 32- or 64-bit.
>
> Thus add an `into()` call to support the 32-bit case, while allowing the
> Clippy lint that complains in the 64-bit case where the type is the same.
>
> Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
> As discussed, it may be best to have a newtype, or at least a function
> to perform this -- here it is the minimal fix nevertheless.
I agree we should at least have a specific conversion function, but for now:
Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com>
Cheers Christian
On Thu Jul 24, 2025 at 6:54 PM CEST, Miguel Ojeda wrote:
> In 32-bit arm, the build fails with:
>
> error[E0308]: mismatched types
> --> drivers/gpu/drm/nova/file.rs:42:28
> |
> 42 | getparam.set_value(value);
> | --------- ^^^^^ expected `u64`, found `u32`
> | |
> | arguments to this method are incorrect
> |
> note: method defined here
> --> drivers/gpu/drm/nova/uapi.rs:29:12
> |
> 29 | pub fn set_value(&self, v: u64) {
> | ^^^^^^^^^ ------
> help: you can convert a `u32` to a `u64`
> |
> 42 | getparam.set_value(value.into());
> | +++++++
>
> The reason is that `Getparam::set_value` takes a `u64` (from the UAPI),
> but `pci::Device::resource_len()` returns a `resource_size_t`, which is a
> `phys_addr_t`, which may be 32- or 64-bit.
>
> Thus add an `into()` call to support the 32-bit case, while allowing the
> Clippy lint that complains in the 64-bit case where the type is the same.
>
> Fixes: cdeaeb9dd762 ("drm: nova-drm: add initial driver skeleton")
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Thanks -- will take it through -fixes once rc-1 is out.
> ---
> As discussed, it may be best to have a newtype, or at least a function
> to perform this -- here it is the minimal fix nevertheless.
I think I will follow up with a function to perform the conversion in a single
place, but I really like the idea of a special clippy annotation to tell clippy
to not warn about unnecessary into() conversions for a specific type alias, such
as ResourceSize.
Do we agree that we want something like this? Do we even have a feature request
for this already?
On Thu, Jul 24, 2025 at 7:05 PM Danilo Krummrich <dakr@kernel.org> wrote: > > Thanks -- will take it through -fixes once rc-1 is out. By the way, in that case we should probably: Cc: stable@vger.kernel.org Cheers, Miguel
On Thu, Jul 24, 2025 at 7:05 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> I think I will follow up with a function to perform the conversion in a single
> place, but I really like the idea of a special clippy annotation to tell clippy
> to not warn about unnecessary into() conversions for a specific type alias, such
> as ResourceSize.
>
> Do we agree that we want something like this? Do we even have a feature request
> for this already?
I think we should at least ask -- done here:
https://github.com/rust-lang/rust-clippy/issues/15337
Though, thinking about it, an explicit function may provide value
nevertheless to clearly see where this happens, and it also means that
when we see `into()` we know it cannot be a no-op.
Having said that, regardless of what we do for that lint, giving more
information to the compiler is generally a good idea, even if only for
notes/diagnostics etc.
Cheers,
Miguel
© 2016 - 2025 Red Hat, Inc.