[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjHEOHCf7kAOJOY9bOr9O0CRzxds+8YcXVVGbMZ+7kyXg@mail.gmail.com>
Date: Thu, 2 Apr 2020 13:43:17 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nathan Chancellor <natechancellor@...il.com>
Cc: Dave Airlie <airlied@...il.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>,
Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [git pull] drm for 5.7-rc1
On Thu, Apr 2, 2020 at 1:33 PM Nathan Chancellor
<natechancellor@...il.com> wrote:
>
> This fixes it but I am not sure if it is proper or not (could be
> problematic if CONFIG_PHYS_ADDR_T_64BIT is set but
> CONFIG_ARCH_DMA_ADDR_T_64BIT is not, not sure if that is possible) so I
> figured I'd report it and let you guys deal with it.
Yeah, no, that patch can't be right.
>From your build failure, your configuration has dma_addr_t being a
'long long unsigned int', and map->offset being a resource_size_t is
for just a 'unsigned int'. Casting 'unsigned int *' to 'unsigned long
long *' is not valid.
You'd have to do something like
dma_addr_t temp;
and pass the address of *that* in, and then assign that to map->offset
(and verify that it fits), I think.
That's kind of what the old code did.
Or alternatively, the 'offset' field should just be of type
'dma_addr_t' instead (see include/drm/drm_legacy.h). But I didn't
check if something else wants it to be a resource_size_t.
Linus
Powered by blists - more mailing lists