[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190131104129.GA9241@lst.de>
Date: Thu, 31 Jan 2019 11:41:29 +0100
From: Christoph Hellwig <hch@....de>
To: Joerg Roedel <joro@...tes.org>
Cc: "Michael S . Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
virtualization@...ts.linux-foundation.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
iommu@...ts.linux-foundation.org, jfehlig@...e.com,
jon.grimm@....com, brijesh.singh@....com, jroedel@...e.de,
Thomas.Lendacky@....com
Subject: Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
> +static inline size_t dma_max_mapping_size(struct device *dev)
> +{
> + const struct dma_map_ops *ops = get_dma_ops(dev);
> + size_t size = SIZE_MAX;
> +
> + if (dma_is_direct(ops))
> + size = dma_direct_max_mapping_size(dev);
> + else if (ops && ops->max_mapping_size)
> + size = ops->max_mapping_size(dev);
> +
> + return size;
> +}
Sorry for not noticing last time, but since 5.0 we keep all non-fast
path DMA mapping interfaces out of line, so this should move to
kernel/dma/mapping.c.
> +EXPORT_SYMBOL(dma_direct_max_mapping_size);
And then there is no need to export this one.
The dma_max_mapping_size export should be EXPORT_SYMBOL_GPL like all
new dma-mapping interfaces.
Powered by blists - more mailing lists