On Tue Sep 29, 2026 at 12:05 AM JST, 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. > - 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. :)
Stumbled upon the notes I took while discussing with Danilo so sharing the extra info that was there: - As a consequence of this, the `DmaDevice` trait is likely to go away. - The name of the capabilities struct is not clear yet, but something like `pci::InitTokens` could work (because it would only contain such tokens that reference the device).
