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. :)
