[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa6f49f8-24ea-f166-9c58-aecb13df0418@arm.com>
Date: Mon, 10 Sep 2018 17:06:40 +0100
From: Robin Murphy <robin.murphy@....com>
To: Christoph Hellwig <hch@....de>
Cc: iommu@...ts.linux-foundation.org,
Marek Szyprowski <m.szyprowski@...sung.com>,
Paul Burton <paul.burton@...s.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] dma-mapping: move the dma_coherent flag to struct
device
On 10/09/18 16:47, Christoph Hellwig wrote:
>>> --- a/kernel/dma/Kconfig
>>> +++ b/kernel/dma/Kconfig
>>> @@ -13,6 +13,9 @@ config NEED_DMA_MAP_STATE
>>> config ARCH_DMA_ADDR_T_64BIT
>>> def_bool 64BIT || PHYS_ADDR_T_64BIT
>>> +config ARCH_HAS_DMA_COHERENCE_H
>>> + bool
>>
>> This seems a little crude - is it unbearably churny to make an
>> asm-generic/dma-coherence.h implementation for everyone else?
>
> The case of having something else than the per-device flag is rather
> odd, and I hope we don't grow any new user in addition to mips.
>
> In fact I'm already thinking of ways to get rid of it for mips by
> e.g. iterating over all devices and just setting dma_coherent,
> but for now I wanted to solve the more urgen issues and tackle this
> later, as this unification blocks a few other things
Ah, somehow I started thinking that arm(64) would need to implement
their own as well, but I see the point now. In that case, TBH I'd be
quite happy with just a simple #ifdef CONFIG_MIPS in
linux/dma-noncoherent.h - plus then it looks even more like something
nobody else is expected to do.
>> Nits aside, this otherwise looks sane to me for factoring out the
>> equivalent Xen and arm64 DMA ops cases.
>
> Like this? :)
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-maybe-coherent
Man, that's going to take me a *lot* of time to pick through. All those
horrendous subtleties that I barely remember!
Robin.
Powered by blists - more mailing lists