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