Re: [Xen-devel] [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 10/04/2019 16:27, Thierry Reding wrote:
> On Wed, Apr 10, 2019 at 03:23:27PM +0100, Ian Jackson wrote:
> > From: Wei Liu <wei.liu2@xxxxxxxxxx>
> >
> > Empirically, on stretch armhf:
> >
> >    drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init':
> >    drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc' 
> > from incompatible pointer type [-Werror=incompatible-pointer-types]
> >       pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
> >                                                   ^
> > etc.
> This was fixed in v4.18 by this commit:
>
>         commit 2f8a6da866eff746a9f8c7745790f3765baeb589
>         Author: Emil Goode <emil.fsw@xxxxxxxx>
>         Date:   Wed May 16 12:22:04 2018 +0200
>
>             gpu: host1x: Fix compiler errors by converting to dma_addr_t
>
>             The compiler is complaining with the following errors:
>
>             drivers/gpu/host1x/cdma.c:94:48: error:
>                     passing argument 3 of ‘dma_alloc_wc’ from incompatible 
> pointer type
>                     [-Werror=incompatible-pointer-types]
>
>             drivers/gpu/host1x/cdma.c:113:48: error:
>                     passing argument 3 of ‘dma_alloc_wc’ from incompatible 
> pointer type
>                     [-Werror=incompatible-pointer-types]
>
>             The expected pointer type of the third argument to dma_alloc_wc() is
>             dma_addr_t but phys_addr_t is passed.
>
>             Change the phys member of struct push_buffer to be dma_addr_t so 
> that we
>             pass the correct type to dma_alloc_wc().
>             Also check pb->mapped for non-NULL in the destroy function as that 
> is the
>             right way of checking if dma_alloc_wc() was successful.
>
>             Signed-off-by: Emil Goode <emil.fsw@xxxxxxxx>
>             Signed-off-by: Thierry Reding <treding@xxxxxxxxxx>
>
> It should be fairly easy to backport this to older releases, though I'm
> not sure exactly what made this trigger. This wasn't causing any build
> errors for a very long time, since this type mismatch has existed ever
> since the driver was merged all the way back in v3.10.
Likely no-one ever tried to build this module with CONFIG_XEN=y. Xen requires 
dma_addr_t to be 64-bit regardless the page-tables format selected (e.g short vs 
LPAE).
AFAIK, this is the only case on Arm32 where phys_addr_t and dma_addr_t would 
mismatched.
Ian are we using a different config between Jessie and Stretch?

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel