[PATCH] iommu/io-pgtable-arm: Avoid warning with 32-bit phys_addr_t

[PATCH] iommu/io-pgtable-arm: Avoid warning with 32-bit phys_addr_t

[Robin Murphy]

It's not entirely unreasonable for io-pgtable-arm to be built for
configurations with 32-bit phys_addr_t, where the compiler rightly
raises a warning about the 36-bit shift. That particular code path
should never actually *run* on those systems, but we still want it
to compile cleanly, which is easily done by using an unambiguous u64
as the intermediate type instead.

Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---

Oops, I managed to totally overlook that phys_addr_t would be
configuration-dependent, sorry :(

If this can't sneak in on top of the SMMU pull, I'll resend it 
as a fix for -rc1. It shouldn't be super-critical.

 drivers/iommu/io-pgtable-arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a5be4c92c5c8..47b64d3b833f 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -211,7 +211,7 @@ static arm_lpae_iopte paddr_to_iopte(phys_addr_t paddr,
 static phys_addr_t iopte_to_paddr(arm_lpae_iopte pte,
 				  struct arm_lpae_io_pgtable *data)
 {
-	phys_addr_t paddr = pte & ARM_LPAE_PTE_ADDR_MASK;
+	u64 paddr = pte & ARM_LPAE_PTE_ADDR_MASK;
 
 	if (data->pg_shift < 16)
 		return paddr;
-- 
2.16.1.dirty

Re: [PATCH] iommu/io-pgtable-arm: Avoid warning with 32-bit phys_addr_t

[Joerg Roedel]

On Thu, Mar 29, 2018 at 12:24:52PM +0100, Robin Murphy wrote:
> It's not entirely unreasonable for io-pgtable-arm to be built for
> configurations with 32-bit phys_addr_t, where the compiler rightly
> raises a warning about the 36-bit shift. That particular code path
> should never actually *run* on those systems, but we still want it
> to compile cleanly, which is easily done by using an unambiguous u64
> as the intermediate type instead.
> 
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> 
> Oops, I managed to totally overlook that phys_addr_t would be
> configuration-dependent, sorry :(
> 
> If this can't sneak in on top of the SMMU pull, I'll resend it 
> as a fix for -rc1. It shouldn't be super-critical.
> 
>  drivers/iommu/io-pgtable-arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied it, thanks Robin.