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
| ||
|
Message-ID: <5743BCF5.8030607@rock-chips.com> Date: Tue, 24 May 2016 10:31:17 +0800 From: Shunqian Zheng <zhengsq@...k-chips.com> To: Catalin Marinas <catalin.marinas@....com>, Robin Murphy <robin.murphy@....com> CC: joro@...tes.org, heiko@...ech.de, Mark Rutland <mark.rutland@....com>, linux-rockchip@...ts.infradead.org, iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org, Simon <xxm@...k-chips.com> Subject: Re: [PATCH 4/5] iommu/rockchip: add ARM64 cache flush operation for iommu Catalin, Robin, On 2016年05月23日 21:35, Catalin Marinas wrote: > On Mon, May 23, 2016 at 11:44:14AM +0100, Robin Murphy wrote: >> On 23/05/16 02:37, Shunqian Zheng wrote: >>> From: Simon <xxm@...k-chips.com> >>> >>> Signed-off-by: Simon <xxm@...k-chips.com> >>> --- >>> drivers/iommu/rockchip-iommu.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c >>> index 043d18c..1741b65 100644 >>> --- a/drivers/iommu/rockchip-iommu.c >>> +++ b/drivers/iommu/rockchip-iommu.c >>> @@ -95,12 +95,16 @@ struct rk_iommu { >>> >>> static inline void rk_table_flush(u32 *va, unsigned int count) >>> { >>> +#if defined(CONFIG_ARM) >>> phys_addr_t pa_start = virt_to_phys(va); >>> phys_addr_t pa_end = virt_to_phys(va + count); >>> size_t size = pa_end - pa_start; >>> >>> __cpuc_flush_dcache_area(va, size); >>> outer_flush_range(pa_start, pa_end); >>> +#elif defined(CONFIG_ARM64) >>> + __dma_flush_range(va, va + count); >>> +#endif >> Ugh, please don't use arch-private cache maintenance functions directly from >> a driver. Allocating/mapping page tables to be read by the IOMMU is still >> DMA, so using the DMA APIs is the correct way to manage them, *especially* >> if it needs to work across multiple architectures. It's easier for us if changing the __dma_flush_range() to __flush_dcache_area() is acceptable here? Thank you, - shunqian > I fully agree, these functions should not be used in drivers.
Powered by blists - more mailing lists