diff mbox series

remoteproc/mediatek: fix sparse errors

Message ID 20201116044121.2457272-1-tzungbi@google.com (mailing list archive)
State Superseded
Headers show
Series remoteproc/mediatek: fix sparse errors | expand

Commit Message

Tzung-Bi Shih Nov. 16, 2020, 4:41 a.m. UTC
Fixes the following sparse errors:

warning: incorrect type in argument 2 (different address spaces)
   expected void volatile [noderef] __iomem *addr
   got void *addr
warning: incorrect type in argument 1 (different address spaces)
   expected void *addr
   got void [noderef] __iomem *
warning: incorrect type in assignment (different address spaces)
   expected void [noderef] __iomem *cpu_addr
   got void *
warning: incorrect type in argument 3 (different address spaces)
   expected void *cpu_addr
   got void [noderef] __iomem *cpu_addr

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
---
 drivers/remoteproc/mtk_scp.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

Comments

Nicolas Boichat Nov. 16, 2020, 5:37 a.m. UTC | #1
Hi,

On Mon, Nov 16, 2020 at 12:41 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>
> Fixes the following sparse errors:
>
> warning: incorrect type in argument 2 (different address spaces)
>    expected void volatile [noderef] __iomem *addr
>    got void *addr
> warning: incorrect type in argument 1 (different address spaces)
>    expected void *addr
>    got void [noderef] __iomem *
> warning: incorrect type in assignment (different address spaces)
>    expected void [noderef] __iomem *cpu_addr
>    got void *
> warning: incorrect type in argument 3 (different address spaces)
>    expected void *cpu_addr
>    got void [noderef] __iomem *cpu_addr

Can you also tell us which lines actually fail? Would be easier to
follow (I ended up digging out the test robot email to understand)

>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
> ---
>  drivers/remoteproc/mtk_scp.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index 577cbd5d421e..99d5a4de3e2f 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -298,7 +298,7 @@ static int mt8183_scp_before_load(struct mtk_scp *scp)
>         return 0;
>  }
>
> -static void mt8192_power_on_sram(void *addr)
> +static void mt8192_power_on_sram(void __iomem *addr)
>  {
>         int i;
>
> @@ -307,7 +307,7 @@ static void mt8192_power_on_sram(void *addr)
>         writel(0, addr);
>  }
>
> -static void mt8192_power_off_sram(void *addr)
> +static void mt8192_power_off_sram(void __iomem *addr)
>  {
>         int i;
>

These 2 make sense.

> @@ -556,8 +556,9 @@ static int scp_map_memory_region(struct mtk_scp *scp)
>
>         /* Reserved SCP code size */
>         scp->dram_size = MAX_CODE_SIZE;
> -       scp->cpu_addr = dma_alloc_coherent(scp->dev, scp->dram_size,
> -                                          &scp->dma_addr, GFP_KERNEL);
> +       scp->cpu_addr = (void __iomem *)dma_alloc_coherent(
> +                                       scp->dev, scp->dram_size,
> +                                       &scp->dma_addr, GFP_KERNEL);
>         if (!scp->cpu_addr)
>                 return -ENOMEM;
>

This one looks wrong to me. dma_alloc_coherent memory is not normally
tagged as __iomem. Why is scp->cpu_addr __iomem in the first place?

> @@ -569,8 +570,8 @@ static void scp_unmap_memory_region(struct mtk_scp *scp)
>         if (scp->dram_size == 0)
>                 return;
>
> -       dma_free_coherent(scp->dev, scp->dram_size, scp->cpu_addr,
> -                         scp->dma_addr);
> +       dma_free_coherent(scp->dev, scp->dram_size,
> +                         (void __force *)scp->cpu_addr, scp->dma_addr);
>         of_reserved_mem_device_release(scp->dev);
>  }
>
> --
> 2.29.2.299.gdc1121823c-goog
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Tzung-Bi Shih Nov. 16, 2020, 6:57 a.m. UTC | #2
On Mon, Nov 16, 2020 at 1:38 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
> On Mon, Nov 16, 2020 at 12:41 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
> >
> > Fixes the following sparse errors:
> >
> > warning: incorrect type in argument 2 (different address spaces)
> >    expected void volatile [noderef] __iomem *addr
> >    got void *addr
> > warning: incorrect type in argument 1 (different address spaces)
> >    expected void *addr
> >    got void [noderef] __iomem *
> > warning: incorrect type in assignment (different address spaces)
> >    expected void [noderef] __iomem *cpu_addr
> >    got void *
> > warning: incorrect type in argument 3 (different address spaces)
> >    expected void *cpu_addr
> >    got void [noderef] __iomem *cpu_addr
>
> Can you also tell us which lines actually fail? Would be easier to
> follow (I ended up digging out the test robot email to understand)

Will separate them to make it clear.

> > @@ -556,8 +556,9 @@ static int scp_map_memory_region(struct mtk_scp *scp)
> >
> >         /* Reserved SCP code size */
> >         scp->dram_size = MAX_CODE_SIZE;
> > -       scp->cpu_addr = dma_alloc_coherent(scp->dev, scp->dram_size,
> > -                                          &scp->dma_addr, GFP_KERNEL);
> > +       scp->cpu_addr = (void __iomem *)dma_alloc_coherent(
> > +                                       scp->dev, scp->dram_size,
> > +                                       &scp->dma_addr, GFP_KERNEL);
> >         if (!scp->cpu_addr)
> >                 return -ENOMEM;
> >
>
> This one looks wrong to me. dma_alloc_coherent memory is not normally
> tagged as __iomem. Why is scp->cpu_addr __iomem in the first place?

Did you mean address returns from dma_alloc_coherent() is not normally
a __iomem?

I am wondering if the cpu_addr declaration is somehow misused.
In drivers/remoteproc/mtk_common.h:
> void __iomem *cpu_addr;
diff mbox series

Patch

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 577cbd5d421e..99d5a4de3e2f 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -298,7 +298,7 @@  static int mt8183_scp_before_load(struct mtk_scp *scp)
 	return 0;
 }
 
-static void mt8192_power_on_sram(void *addr)
+static void mt8192_power_on_sram(void __iomem *addr)
 {
 	int i;
 
@@ -307,7 +307,7 @@  static void mt8192_power_on_sram(void *addr)
 	writel(0, addr);
 }
 
-static void mt8192_power_off_sram(void *addr)
+static void mt8192_power_off_sram(void __iomem *addr)
 {
 	int i;
 
@@ -556,8 +556,9 @@  static int scp_map_memory_region(struct mtk_scp *scp)
 
 	/* Reserved SCP code size */
 	scp->dram_size = MAX_CODE_SIZE;
-	scp->cpu_addr = dma_alloc_coherent(scp->dev, scp->dram_size,
-					   &scp->dma_addr, GFP_KERNEL);
+	scp->cpu_addr = (void __iomem *)dma_alloc_coherent(
+					scp->dev, scp->dram_size,
+					&scp->dma_addr, GFP_KERNEL);
 	if (!scp->cpu_addr)
 		return -ENOMEM;
 
@@ -569,8 +570,8 @@  static void scp_unmap_memory_region(struct mtk_scp *scp)
 	if (scp->dram_size == 0)
 		return;
 
-	dma_free_coherent(scp->dev, scp->dram_size, scp->cpu_addr,
-			  scp->dma_addr);
+	dma_free_coherent(scp->dev, scp->dram_size,
+			  (void __force *)scp->cpu_addr, scp->dma_addr);
 	of_reserved_mem_device_release(scp->dev);
 }