On 05/07/17 08:12, Tomasz Figa wrote:
> There is nothing wrong in having a loadable module implementing DMA API,
> for example to be used for sub-devices registered by the module. However,
> most of the functions from dma-iommu do not have their symbols exported,
> making it impossible to use them from loadable modules.
>
> Export all the non-static functions in the file, so that loadable modules
> can benefit from them. Use EXPORT_SYMBOL() for consistency with other
> exports in the file.
To echo what Christoph said, everything not already exported here
shouldn't in any way be considered a driver-facing API in the general
sense, it's horrible glue code to sit behind an arch-specific DMA
mapping implementation (and frankly I'd consider even the current
exports more of an unfortunate abstraction leakage).
> Signed-off-by: Tomasz Figa <tf...@chromium.org>
> ---
[...]
> @@ -829,17 +838,20 @@ dma_addr_t iommu_dma_map_resource(struct device *dev,
> phys_addr_t phys,
> return __iommu_dma_map(dev, phys, size,
> dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
> }
> +EXPORT_SYMBOL(iommu_dma_map_resource);
>
> void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
> size_t size, enum dma_data_direction dir, unsigned long attrs)
> {
> __iommu_dma_unmap(iommu_get_domain_for_dev(dev), handle, size);
> }
> +EXPORT_SYMBOL(iommu_dma_unmap_resource);
Do you need these two? Unless your custom DMA ops really have to support
slave DMA or other peer-to-peer traffic through their IOMMU, I'd be more
inclined to implement dma_map_resource as "return 0;" and ignore
dma_unmap_resource.
> @@ -913,3 +925,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
> msg->address_lo += lower_32_bits(msi_page->iova);
> }
> }
> +EXPORT_SYMBOL(iommu_dma_map_msi_msg);
Given the nature of the kind of irqchip drivers this exists for, the
chances of one ever being modular seem vanishingly small.
Robin.
