[PATCH] remoteproc/mediatek: fix sparse errors

[Tzung-Bi Shih]

On Mon, Nov 16, 2020 at 1:38 PM Nicolas Boichat <drinkcat at chromium.org> wrote:
> On Mon, Nov 16, 2020 at 12:41 PM Tzung-Bi Shih <tzungbi at 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;