From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH 2/2] swiotlb-xen: xen_swiotlb_map_page: do not error out if dma_capable fails
Date: Tue, 12 Nov 2013 15:05:41 +0000 [thread overview]
Message-ID: <20131112150540.GN16735@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20131112144832.GC9435@phenom.dumpdata.com>
On Tue, Nov 12, 2013 at 09:48:32AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 12, 2013 at 02:12:00PM +0000, Stefano Stabellini wrote:
> > Many ARM devices do not set the dma_mask correctly today.
> > As a consequence dma_capable fails for them regardless of the address
> > passed to it.
>
> Wouldn't the DMA API debug warn of bad usage.
No. The problem is that dev->dma_mask is NULL, and that's generally
interpreted as "this device doesn't do DMA".
ARM drivers have been particularly bad in respect of getting this right:
there's an overwhelming problem here of "I don't need to do that so I'm
not going to do it" rather than taking the attitude of "it's good
practice to do X because it will save me hastles in the future".
I'll admit that even I'm guilty of the former in this regard to some
extent: I've not added the necessary dma_set_mask/dma_set_coherent_mask()
calls to the various drivers because they haven't been a concern. That
was wrong, because the DMA API technically requires it.
However, not having a DMA mask set when the device is created is
something I'm not guilty of - I always ensured with the old board
files that a DMA capabable device had a DMA mask set and those which
weren't capable didn't: this causes the DMA API to behave correctly
and report according to the way the device was declared whether it is
DMA capable or not.
Unfortunately, others decided (especially post DT) that the solution
to this was to have the driver code - which could be modular - do things
like this:
static u64 mask = blah;
foo_probe(dev)
{
if (!dev->dma_mask)
dev->dma_mask = &mask;
}
which works nicely until you reload the module.
I strongly suggest _not_ working around this problem in subsystem code
but raising bug reports against the buggy drivers. All drivers without
exception using DMA should have something like this pattern:
foo_probe(dev)
{
int rc;
rc = dma_set_mask(dev, DMA_BIT_MASK(bits));
if (rc)
return rc;
dma_set_coherent_mask(dev, DMA_BIT_MASK(bits));
...
}
The first call is required if the driver uses dma_map_*, the second call
is required if it makes use of coherent allocations and can be of the
above form if it's previously used dma_set_mask with the same mask.
Otherwise, the return value of dma_set_coherent_mask() must be checked.
Of course, dma_set_mask() will fail if dev->dma_mask is NULL - and that's
something which must be fixed where the device was created, not by the
driver.
next prev parent reply other threads:[~2013-11-12 15:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 14:11 [PATCH 0/2] swiotlb-xen fixes Stefano Stabellini
2013-11-12 14:11 ` [PATCH 1/2] swiotlb-xen: add missing xen_dma_map_page call Stefano Stabellini
2013-11-12 14:45 ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-11-12 17:03 ` Stefano Stabellini
2013-11-12 14:12 ` [PATCH 2/2] swiotlb-xen: xen_swiotlb_map_page: do not error out if dma_capable fails Stefano Stabellini
2013-11-12 14:48 ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-11-12 15:05 ` Russell King - ARM Linux [this message]
2013-11-12 17:27 ` Stefano Stabellini
2013-11-12 20:22 ` Rob Herring
2013-11-13 11:35 ` Stefano Stabellini
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=20131112150540.GN16735@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).