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

["Gary Guo" <gary@garyguo.net>]

On Mon Sep 28, 2026 at 4:05 PM BST, Alexandre Courbot wrote:
> On Mon Sep 28, 2026 at 7:44 AM JST, Matteo Kloiber wrote:
>> First of all, thanks for merging my first two patches and sorry about my late reply.
>>
>> What I think Alex meant and what I agree with is that the new API should focus on
>> making semantic bugs harder, not to necessarily make it easier to write safer
>> drivers. That being said, I think we can do both with this change.
>>
>> The key change here is that we introduce a structure that defines dma
>> parameters for a device. This structure deliberately has no default
>> implementation and new fields should be added even if they require changes for
>> all dma drivers.
> <...>
>
> Thanks for the detailed plan; I think it mostly makes sense.
>
> A few details that we have discussed offline with Danilo:
>
> - The `probe` methods should not take the `dma::Setup` token directly,
>   but rather a bus-specific struct that contains it and can be augmented
>   with other capabilities. Drivers would have to deconstruct it using
>   the `..` operator to make sure code doesn't break if we add new tokens
>   to it.

I was quite skeptical whether the complication of adding the dma setup token is
worth the effort, but the capacity struct sounds like a very nice design as it's
infinitely extensible. I can foresee that we might want to eventually get rid of
the special `Core` typestate and just replace everything with setup
capabilities.

Best,
Gary

> - The token should not assume default parameters and only call functions
>   corresponding to parameters explicitly set; converting the token to a
>   handler means the driver acknowledged all the settings, so we should
>   not make any parameter mandatory (the doc should of course detail what
>   drivers *should* do).
>
> With that and your plan I believe you have a solid basis to send a
> RFC/PoC. :)