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]
Message-id: <338cbdc6-2830-813b-713e-1cc40d23d1f9@samsung.com>
Date:	Thu, 09 Jun 2016 08:51:18 +0200
From:	Marek Szyprowski <m.szyprowski@...sung.com>
To:	Matthew Leach <matthew@...tleach.net>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>
Cc:	linux-samsung-soc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Joerg Roedel <joro@...tes.org>, Kukjin Kim <kgene@...nel.org>,
	iommu@...ts.linux-foundation.org
Subject: Re: [RFC PATCH 15/15] iommu/exynos: update to use iommu big-endian

Hi


On 2016-06-08 20:31, Matthew Leach wrote:
> From: Ben Dooks <ben.dooks@...ethink.co.uk>
>
> Add initial support for big endian by always writing the pte
> in le32. Note, revisit if hardware capable of doing big endian
> fetches.
>
> Signed-off-by: Ben Dooks <ben.dooks@...ethink.co.uk>

Acked-by: Marek Szyprowski <m.szyprowski@...sung.com>

Just to keep my curiosity satisfied - what's the reason to use
big-endian on ARM?

Good luck with fixing the kernel and userspace codes, which usually
assume little-endian is the only possible order!

> ---
> Cc: Marek Szyprowski <m.szyprowski@...sung.com>
> Cc: Joerg Roedel <joro@...tes.org>
> Cc: Kukjin Kim <kgene@...nel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@...sung.com>
> Cc: iommu@...ts.linux-foundation.org
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-samsung-soc@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org (open list)
> ---
>   drivers/iommu/exynos-iommu.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 5ecc86c..dd8b3b3 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -54,6 +54,10 @@ typedef u32 sysmmu_pte_t;
>   #define lv2ent_small(pent) ((*(pent) & 2) == 2)
>   #define lv2ent_large(pent) ((*(pent) & 3) == 1)
>   
> +#ifdef CONFIG_BIG_ENDIAN
> +#warning "revisit driver if we can enable big-endian ptes"
> +#endif
> +

This warning can be removed. There is no way to force SYSMMU to operate with
big-endian PTEs according to the datasheet.

>   /*
>    * v1.x - v3.x SYSMMU supports 32bit physical and 32bit virtual address spaces
>    * v5.0 introduced support for 36bit physical address space by shifting
> @@ -716,7 +720,7 @@ static inline void update_pte(sysmmu_pte_t *ent, sysmmu_pte_t val)
>   {
>   	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent), sizeof(*ent),
>   				DMA_TO_DEVICE);
> -	*ent = val;
> +	*ent = cpu_to_le32(val);
>   	dma_sync_single_for_device(dma_dev, virt_to_phys(ent), sizeof(*ent),
>   				   DMA_TO_DEVICE);
>   }

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ