[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DBEL719XP5CO.FKBDQ4QRZST0@kernel.org>
Date: Thu, 17 Jul 2025 21:45:26 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Daniel Almeida" <daniel.almeida@...labora.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
<alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
<gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
"Trevor Gross" <tmgross@...ch.edu>, "Greg Kroah-Hartman"
<gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
<linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v15 2/3] rust: io: mem: add a generic iomem abstraction
On Thu Jul 17, 2025 at 5:55 PM CEST, Daniel Almeida wrote:
> +impl<const SIZE: usize> IoMem<SIZE> {
> + fn ioremap(resource: &Resource) -> Result<Self> {
> + // Note: It looks like there aren't any 32-bit architectures that define
> + // ioremap_np. This means that sometimes this conversion will fail. If
> + // we performed a lossy cast, i.e., using `as`, then `bindings::ioremap`
> + // would return NULL anyway.
Why would ioremap() return NULL if you perform a lossy cast?
Anyways, I find it a bit difficult to decode the actual problem from the above
description.
I feel it would be better to just explain that some ioremap() implementations
use types that depend on the CPU word width rather than the bus address width.
If you agree, no need to resend though, we can change it when applying the
series.
> + // TODO: Properly address this in the C code to avoid this `try_into`.
> + let size = resource.size().try_into()?;
> + if size == 0 {
> + return Err(EINVAL);
> + }
Powered by blists - more mailing lists