From: Robin Murphy <robin.murphy@arm.com>
To: Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
linux-renesas-soc@vger.kernel.org,
Simon Horman <horms@verge.net.au>,
Bjorn Helgaas <bhelgaas@google.com>,
fkan@apm.com
Subject: Re: [PATCH] arm64: avoid increasing DMA masks above what hardware supports
Date: Wed, 11 Jan 2017 14:50:31 +0000 [thread overview]
Message-ID: <c5bada32-fbaf-3631-268b-db49dffe3eb9@arm.com> (raw)
In-Reply-To: <09cac197-9e57-5d3e-e742-f29c00051813@cogentembedded.com>
On 11/01/17 13:41, Nikita Yushchenko wrote:
>> Yes, I think that ought to work, although the __iommu_setup_dma_ops()
>> call will still want a real size reflecting the default mask
>
> I see iommu_dma_ops do not define set_dma_mask.
>
> So what if setup was done for size reflecting one mask and then driver
> changes mask? Will things still operate correctly?
We've overridden dma_set_mask() at the function level, so it should
always apply regardless. Besides, none of the arm64 ops implement
.set_dma_mask anyway, so we could possibly drop the references to it
altogether.
Conversely, I suppose we could just implement said callback for
swiotlb_dma_ops and iommu_dma_ops with the parent_dma_mask-checking
function and drop the HAVE_ARCH_DMA_SET_MASK override instead. I'm not
sure which approach is preferable - the latter seems arguably cleaner in
isolation, but would also be less consistent with how the coherent mask
has to be handled. Ho hum.
Robin.
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: avoid increasing DMA masks above what hardware supports
Date: Wed, 11 Jan 2017 14:50:31 +0000 [thread overview]
Message-ID: <c5bada32-fbaf-3631-268b-db49dffe3eb9@arm.com> (raw)
In-Reply-To: <09cac197-9e57-5d3e-e742-f29c00051813@cogentembedded.com>
On 11/01/17 13:41, Nikita Yushchenko wrote:
>> Yes, I think that ought to work, although the __iommu_setup_dma_ops()
>> call will still want a real size reflecting the default mask
>
> I see iommu_dma_ops do not define set_dma_mask.
>
> So what if setup was done for size reflecting one mask and then driver
> changes mask? Will things still operate correctly?
We've overridden dma_set_mask() at the function level, so it should
always apply regardless. Besides, none of the arm64 ops implement
.set_dma_mask anyway, so we could possibly drop the references to it
altogether.
Conversely, I suppose we could just implement said callback for
swiotlb_dma_ops and iommu_dma_ops with the parent_dma_mask-checking
function and drop the HAVE_ARCH_DMA_SET_MASK override instead. I'm not
sure which approach is preferable - the latter seems arguably cleaner in
isolation, but would also be less consistent with how the coherent mask
has to be handled. Ho hum.
Robin.
next prev parent reply other threads:[~2017-01-11 14:51 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-09 7:30 [PATCH v2] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko
2017-01-09 7:30 ` Nikita Yushchenko
2017-01-10 11:51 ` Will Deacon
2017-01-10 11:51 ` Will Deacon
2017-01-10 12:47 ` Nikita Yushchenko
2017-01-10 12:47 ` Nikita Yushchenko
2017-01-10 13:12 ` Arnd Bergmann
2017-01-10 13:12 ` Arnd Bergmann
2017-01-10 13:25 ` Robin Murphy
2017-01-10 13:25 ` Robin Murphy
2017-01-10 13:42 ` Arnd Bergmann
2017-01-10 13:42 ` Arnd Bergmann
2017-01-10 14:16 ` Robin Murphy
2017-01-10 14:16 ` Robin Murphy
2017-01-10 15:06 ` Arnd Bergmann
2017-01-10 15:06 ` Arnd Bergmann
2017-01-11 12:37 ` Nikita Yushchenko
2017-01-11 12:37 ` Nikita Yushchenko
2017-01-11 16:21 ` Arnd Bergmann
2017-01-11 16:21 ` Arnd Bergmann
2017-01-11 18:28 ` Robin Murphy
2017-01-11 18:28 ` Robin Murphy
2017-01-10 14:59 ` Christoph Hellwig
2017-01-10 14:59 ` Christoph Hellwig
2017-01-10 14:00 ` [PATCH] arm64: avoid increasing DMA masks above what hardware supports Nikita Yushchenko
2017-01-10 14:00 ` Nikita Yushchenko
2017-01-10 17:14 ` Robin Murphy
2017-01-10 17:14 ` Robin Murphy
2017-01-11 7:59 ` Nikita Yushchenko
2017-01-11 7:59 ` Nikita Yushchenko
2017-01-11 11:54 ` Robin Murphy
2017-01-11 11:54 ` Robin Murphy
2017-01-11 13:41 ` Nikita Yushchenko
2017-01-11 13:41 ` Nikita Yushchenko
2017-01-11 14:50 ` Robin Murphy [this message]
2017-01-11 14:50 ` Robin Murphy
2017-01-11 16:03 ` Nikita Yushchenko
2017-01-11 16:50 ` Robin Murphy
2017-01-11 16:50 ` Robin Murphy
2017-01-11 18:31 ` [PATCH 0/2] arm64: fix handling of DMA masks wider than bus supports Nikita Yushchenko
2017-01-11 18:31 ` Nikita Yushchenko
2017-01-11 18:31 ` [PATCH 1/2] dma-mapping: let arch know origin of dma range passed to arch_setup_dma_ops() Nikita Yushchenko
2017-01-11 18:31 ` Nikita Yushchenko
2017-01-11 21:08 ` Arnd Bergmann
2017-01-11 21:08 ` Arnd Bergmann
2017-01-12 5:52 ` Nikita Yushchenko
2017-01-12 5:52 ` Nikita Yushchenko
2017-01-12 6:33 ` Nikita Yushchenko
2017-01-12 6:33 ` Nikita Yushchenko
2017-01-12 13:28 ` Arnd Bergmann
2017-01-12 13:28 ` Arnd Bergmann
2017-01-12 13:39 ` Nikita Yushchenko
2017-01-12 13:39 ` Nikita Yushchenko
2017-01-12 12:16 ` Will Deacon
2017-01-12 12:16 ` Will Deacon
2017-01-12 13:25 ` Arnd Bergmann
2017-01-12 13:25 ` Arnd Bergmann
2017-01-12 13:43 ` Robin Murphy
2017-01-12 13:43 ` Robin Murphy
2017-01-13 10:40 ` kbuild test robot
2017-01-13 10:40 ` kbuild test robot
2017-01-11 18:31 ` [PATCH 2/2] arm64: avoid increasing DMA masks above what hardware supports Nikita Yushchenko
2017-01-11 18:31 ` Nikita Yushchenko
2017-01-11 21:11 ` Arnd Bergmann
2017-01-11 21:11 ` Arnd Bergmann
2017-01-12 5:53 ` Nikita Yushchenko
2017-01-12 5:53 ` Nikita Yushchenko
2017-01-13 10:16 ` kbuild test robot
2017-01-13 10:16 ` kbuild test robot
2017-01-10 14:01 ` [PATCH v2] arm64: do not set dma masks that device connection can't handle Nikita Yushchenko
2017-01-10 14:01 ` Nikita Yushchenko
2017-01-10 14:57 ` Christoph Hellwig
2017-01-10 14:57 ` Christoph Hellwig
2017-01-10 14:51 ` Christoph Hellwig
2017-01-10 14:51 ` 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=c5bada32-fbaf-3631-268b-db49dffe3eb9@arm.com \
--to=robin.murphy@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=fkan@apm.com \
--cc=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=nikita.yoush@cogentembedded.com \
--cc=will.deacon@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.