Re: [PATCH 2/2] rust: scatterlist: honor the device's maximum segment size

[Robin Murphy <robin.murphy@arm.com>]

On 14/09/2026 11:22 am, Gary Guo wrote:
> On Mon Sep 14, 2026 at 10:58 AM BST, Danilo Krummrich wrote:
>> On Mon Sep 14, 2026 at 2:45 AM CEST, Alexandre Courbot wrote:
>>> On Mon Sep 14, 2026 at 6:08 AM JST, Matteo Kloiber wrote:
>>>> On Mon Sep 7, 2026 at 11:43 AM JST, Alexandre Courbot wrote:
>>>>> It also means that without patch 1, nova-core would split the firmware
>>>>> into hundreds of 64KB SG entries, which is not breaking but still
>>>>> something we want to avoid. The correct fix is to make sure that
>>>>> `dma_set_max_seg_size` is called by the driver, and while we are at it
>>>>> we also want every driver to call `dma_set_mask_and_coherent`. Ideally
>>>>> we would use the type system to make sure that both functions are called
>>>>> before any DMA operation can take place (using a safe interface), but
>>>>> I'm not quite sure yet how we can do this.
>>>>
>>>> This sounds sensible indeed. Should I open a thread regarding that on Zulip?
>>>
>>> Probably not necessary, the mailing-list has a larger audience and is
>>> the right place for this. I expect people will jump in here with their
>>> thoughts.
>>
>> The problem with those is not that they must strictly be called before
>> allocating DMA memory, but they must not be called concurrently with other DMA
>> operations, such as allocating DMA memory, as it would technically be a data
>> race.
> 
> Do they really have to be called *before* allocating DMA memory, not do they
> just need not be called *concurrent* to DMA memory allocation?

Similar to DMA masks, the segment parameters should be set appropriately 
before any dma_map_sg() operation. Plus since they likely influence 
scatterlist geometry, that means typically they're also going to need to 
be set before building the scatterlist to be mapped in the first place.

I don't think there's any expectation that they would ever change 
*between* different mappings - especially given the underlying hardware 
properties they represent - so while that might technically be possible 
in the C API if the caller can enforce sufficient ordering, it should be 
fine to rule it out in the Rust abstraction if that makes things easier 
to reason about.

Thanks,
Robin.

> If it's the former, we can require these to require mutable reference instead,
> so the probe takes `Pin<&'bound mut Device<Core<'_>>>` which still derefs to
> `&'bound Device<Bound>`, but Rust will require the shared reference to not
> co-exist with the mutable reference.
> 
> Best,
> Gary
>