Re: [PATCH v14 2/3] rust: io: mem: add a generic iomem abstraction

[Danilo Krummrich]

On Wed Jul 16, 2025 at 11:52 PM CEST, Daniel Almeida wrote:
> Hi,
>
> […]
>
>> +
>> +/// An exclusive memory-mapped IO region.
>> +///
>> +/// # Invariants
>> +///
>> +/// - [`ExclusiveIoMem`] has exclusive access to the underlying [`IoMem`].
>> +pub struct ExclusiveIoMem<const SIZE: usize> {
>> +    /// The underlying `IoMem` instance.
>> +    iomem: IoMem<SIZE>,
>> +
>> +    /// The region abstraction. This represents exclusive access to the
>> +    /// range represented by the underlying `iomem`.
>> +    ///
>> +    /// This field is needed for ownership of the region.
>> +    _region: Region,
>> +}
>> +
>> +impl<const SIZE: usize> ExclusiveIoMem<SIZE> {
>> +    /// Creates a new `ExclusiveIoMem` instance.
>> +    fn ioremap(resource: &Resource) -> Result<Self> {
>> +        let start = resource.start();
>> +        let size = resource.size();
>> +        let name = resource.name().ok_or(EINVAL)?;
>
> Note the change above. If there’s no name, we fail.
>
> I just noticed that this may not be the right approach, but OTOH we should note that
> “not having a name” is apparently considered a bug in the C code under some
> circumstances:

If we'd consider it to be a bug strictly speaking we should not make it an
Option and fix the bugs instead.

However, I don't think this is a bug, there are plenty of "constructor" macros
that create resource structures with a NULL pointer for the name field
(DEFINE_RES_IRQ(),  DEFINE_RES_REG(), etc.).

Besides that, also the C APIs do the name check, __devm_ioremap_resource() [1]
is such an example.

Busses often assign the corresponding device name later on, but I wouldn't bet
on this to be a hard rule and nothing this abstraction can rely on anyways.

I think we should just pick a fallback string.

[1] https://elixir.bootlin.com/linux/v6.15.6/source/lib/devres.c#L144