[discussion about this patch, which should have been cced to the iommu and linux-arm-kernel lists, but wasn't: https://www.spinics.net/lists/dri-devel/msg173630.html] On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote: > > API from the iommu/dma-mapping code. Drivers have no business poking > > into these details. > > The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL, > which is rather misleading if they are not meant to be used by drivers > directly. The only reason the DMA ops are exported is because get_arch_dma_ops references (or in case of the coherent ones used to reference). We don't let drivers assign random dma ops. > > > Thierry, please resend this with at least the iommu list and > > linux-arm-kernel in Cc to have a proper discussion on the right API. > > I'm certainly open to help with finding a correct solution, but the > patch above was purposefully terse because this is something that I > hope we can get backported to v4.16 to unbreak Nouveau. Coordinating > such a backport between ARM and DRM trees does not sound like something > that would help getting this fixed in v4.16. Coordinating the backport of a trivial helper in the arm tree is not the end of the world. Really, this cowboy attitude is a good reason why graphics folks have such a bad rep. You keep poking into random kernel internals, don't talk to anoyone and then complain if people are upset. This shouldn't be surprising. > Granted, this issue could've been caught with a little more testing, but > in retrospect I think it would've been a lot better if ARM_DMA_USE_IOMMU > was just enabled unconditionally if it has side-effects that platforms > don't opt in to but have to explicitly opt out of. Agreed on that count. Please send a patch.
