lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ