On Tue Jul 8, 2025 at 10:40 AM CEST, Danilo Krummrich wrote: > On Tue Jul 8, 2025 at 8:04 AM CEST, Alistair Popple wrote: >> Add bindings to allow setting the DMA masks for both a generic device >> and a PCI device. > > Nice coincidence, I was about to get back to this. I already implemented this in > a previous patch [1], but didn't apply it yet. > > I think the approach below is thought a bit too simple: > > (1) We want the DMA mask methods to be implemented by a trait in dma.rs. > Subsequently, the trait should only be implemented by bus devices where > the bus actually supports DMA. Allowing to set the DMA mask on any device > doesn't make sense. Forgot to mention, another reason for a trait is that we can also use it as a trait bound on dma::CoherentAllocation::new(), such that people can't pass arbitrary devices to dma::CoherentAllocation::new(), but only those that actually sit on a DMA capable bus. > > (2) We need to consider that with this we do no prevent > dma_set_coherent_mask() to concurrently with dma_alloc_coherent() (not > even if we'd add a new `Probe` device context). > > (2) is the main reason why I didn't follow up yet. So far I haven't found a nice > solution for a sound API that doesn't need unsafe. > > One thing I did consider was to have some kind of per device table (similar to > the device ID table) for drivers to specify the DMA mask already at compile > time. However, I'm pretty sure there are cases where the DMA mask has to derived > dynamically from probe(). > > I think I have to think a bit more about it. > > [1] https://lore.kernel.org/all/20250317185345.2608976-7-abdiel.janulgue@xxxxxxxxx/
