Re: [PATCH v6 7/8] rust: Introduce iosys_map bindings

[Daniel Almeida <daniel.almeida@collabora.com>]

> On 14 Jan 2026, at 20:21, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> (Cc: Zhi, Matt, Alex)
> 
> On Tue Dec 2, 2025 at 11:03 PM CET, Lyude Paul wrote:
>> This introduces a set of bindings for working with iosys_map in rust code.
>> The design of this is heavily based off the design for both the io and
>> dma_map bindings for Rust.
> 
> I already had a chat with Lyude about this, but also want to post it here. I
> have mainly two comment on this:
> 
>  (1) The backing memory of iosys_map may be a device resource and hence has to
>      be protected against (bus) device / driver unbind.
> 
>  (2) The idea for the generic I/O infrastructure is to support arbitrary I/O
>      backends rather than only MMIO. For instance, this can also be PCI
>      configuration space, I2C, SPI, etc., but also DMA, VRAM, system memory,
>      etc.
> 
>      For this, there is a patch series from Zhi [1] splitting up the current
>      I/O structures into traits that we will land soon.
> 
>      We will also have macros analogous to dma_read!() and dma_write!() for the
>      generic I/O infrastructure, which Matt also works on for his QC SoC
>      driver.
> 
>      This will allow us to unify all kinds of I/O operations into a single
>      interface, supporting the read!() and write!() accessors for values, the
>      register!() macro and raw accessors, such as e.g. read32().
> 
>      With this we will have something that is way more powerful than iosys_map
>      and makes this abstraction obsolete.
> 
> So instead of introducing an abstraction for iosys_map we should just implement
> the corresponding I/O backends based on [1].
> 
> [1] https://lore.kernel.org/all/20260113092253.220346-3-zhiw@nvidia.com/
> 

I wonder if we can combine this with the idea of splitting I/O ranges that
we have been discussing for a while. It is a simple concept: you might have a
mapping that covers a given length (say, a single BO), but this mapping might
be split into multiple subregions that are not accessed simultaneously. This
allows for finer-grain control, as subregions are isolated from each other.

If the idea is to have all these types eventually dereference to “Io”
or something like this, the above may be as simple as adding a
“split()” method which generates a second Io while simultaneously
adjusting the bounds as needed.

If this is a good idea then I can spend cycles, as I’ll have a use for that in Tyr.

— Daniel