Re: [git pull] drm for 5.7-rc1

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Thu, Apr 2, 2020 at 10:43 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, Apr 2, 2020 at 1:33 PM Nathan Chancellor
> <natechancellor@gmail.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.

This is all exclusive in legacy code back from the days when drm
drivers where shared with *bsd. None of that code ever learned that
there's maybe a difference between dma/phys/virtual address sizes, and
that's about the least of the problems it has.

Revert seems to be clean, I'd vote for that. And maybe we instead try
to push these horrors more under the CONFIG_DRM_LEGACY. I'll try to
remember to do that, afaics the only thing outside are the
drm_pci_alloc/free multi-layered wrappers in drm_pci.c.

Linus, can you pls push the revert yourself, to avoid build bot
breakage for longer than necessary?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch