From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: hch@lst.de, m.szyprowski@samsung.com,
iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 2/2] dma-mapping: Clean up dma_get_required_mask() hooks
Date: Tue, 10 Jul 2018 13:39:08 +0200 [thread overview]
Message-ID: <20180710113908.GB32688@lst.de> (raw)
In-Reply-To: <08256121f325ceed7f6b88c1a5d3cf949698787d.1530726467.git.robin.murphy@arm.com>
On Wed, Jul 04, 2018 at 06:50:12PM +0100, Robin Murphy wrote:
> As for the other mask-related hooks, standardise the arch override into
> a Kconfig option, and also pull the generic implementation into the DMA
> mapping code rather than having it hide away in the platform bus code.
I compared this a bit to what I had around against an older kernel,
and I think we should probably go with something more like the
version I had, which I can dust off again.
What I've done is to:
1) provide the get_required_mask unconditionally in struct dma_map_ops
2) default to what is the current dma_get_required_mask implementation
if nothing else is specified.
What I still had on my todo list but not done yet:
3) go through all instances and check if the current default
makes sense, at it based on direct addressability. For most
iommu instances it seems like we should just return a 64-bit mask.
4) figure out how to take the dma offsets into account for it
5) move the function to the dma-direct code, as that is where it
belongs
5) figure out if there is a better name for the method, as with
swiotlb & co it isn't really the required mask, but more something
like the optimal mask
6) document the whole thing..
7) sort out the powerpc indirection mess.
Do you agree with that general plan? If so I can dust off my old
patch.
next prev parent reply other threads:[~2018-07-10 11:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 17:50 [RFC PATCH 1/2] dma-mapping: Clean up dma_set_*mask() hooks Robin Murphy
2018-07-04 17:50 ` [RFC PATCH 2/2] dma-mapping: Clean up dma_get_required_mask() hooks Robin Murphy
2018-07-05 19:38 ` Christoph Hellwig
2018-07-06 14:22 ` Robin Murphy
2018-07-10 11:39 ` Christoph Hellwig [this message]
2018-07-10 12:29 ` Robin Murphy
2018-07-10 15:08 ` Christoph Hellwig
2018-07-05 19:37 ` [RFC PATCH 1/2] dma-mapping: Clean up dma_set_*mask() hooks Christoph Hellwig
2018-07-06 14:20 ` Robin Murphy
2018-07-08 15:07 ` Christoph Hellwig
2018-07-09 14:53 ` Robin Murphy
2018-07-10 11:44 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180710113908.GB32688@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).