From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Christoph Hellwig <hch@lst.de>, Jia He <justin.he@arm.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] dma-mapping: fix dma_addressing_limited if dma_range_map can't cover all system RAM
Date: Wed, 11 Oct 2023 07:11:00 +0200 [thread overview]
Message-ID: <20231011051100.GB32642@lst.de> (raw)
In-Reply-To: <39d5aabd-4c09-4135-a3d7-00f6da7a1684@arm.com>
On Tue, Oct 10, 2023 at 10:40:44AM +0100, Robin Murphy wrote:
> On 2023-10-10 08:48, Christoph Hellwig wrote:
>> dma_addressing_limited is called for every dma (direct) map, and this
>> new code is way to heavy for that. We'll need to cache the information
>> somehow.
>
> But is it? That was my instinctive reaction as well, but AFAICS it is only
> actually used by drivers in setup paths, either directly or via
> dma_max_mapping_size(). The dma_capable() check which we *do* use for every
> actual mapping still just checks whether the given physical address exists
> in the range map. I believe the underlying problem here is when
> dma_capable() say the mapping needs bouncing, but then it's too big for
> that to succeed, since dma_max_mapping_size() gave the wrong answer to
> start with.
Ah, indeed, I somehw misremembered calling it in the mapping code.
Justing, can you still respin this a bit, add a prep patch to move
dma_addressing_limited so that it is exported instead of the new
low-level helper, and fix up coding style issues like the overly
long lines of possible? If it's not perfect I'll fix up the rest
later.
next prev parent reply other threads:[~2023-10-11 5:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 2:08 [PATCH v2] dma-mapping: fix dma_addressing_limited if dma_range_map can't cover all system RAM Jia He
2023-10-10 7:48 ` Christoph Hellwig
2023-10-10 8:42 ` Justin He
2023-10-10 9:40 ` Robin Murphy
2023-10-11 5:11 ` Christoph Hellwig [this message]
2023-10-16 2:59 ` Justin He
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=20231011051100.GB32642@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=justin.he@arm.com \
--cc=linux-kernel@vger.kernel.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