linux-kernel - Re: [git pull] drm tree for 5.4-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Sep 2019 14:26:12 +0900
From:   Alexandre Courbot <acourbot@...omium.org>
To:     Dave Airlie <airlied@...il.com>, CK Hu <ck.hu@...iatek.com>,
        Tomasz Figa <tfiga@...omium.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm tree for 5.4-rc1

On Fri, Sep 20, 2019 at 9:11 AM Dave Airlie <airlied@...il.com> wrote:
>
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
> > drm_gem_prime_export, because it's the default if none exists. That's
> > the left-over from
> >
> >     3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
> >
> > after the import stayed around because it got turned into an actually
> > non-default one.
> >
> > I think that both of our merges are right - equivalent but just
> > slightly different.
> >
> > But the reason I'm pointing this out is that I also get the feeling
> > that if it needs that dev->dev_private difference from the default
> > function in prime_import(), wouldn't it need the same for prime_export
> > too?
> >
> > I don't know the code, and I don't know the hardware, but just from a
> > "pattern matching" angle I just wanted to check whether maybe there's
> > need for a mtk_drm_gem_prime_export() wrapper that does that same
> > thing with
> >
> >         struct mtk_drm_private *private = dev->dev_private;
> >
> >         .. use private->dev  instead of dev->dev ..
> >
> > So I'm just asking that somebody that knows that drm/mtk code should
> > double-check that oddity.
>
> I've cc'ed Alexandre who wrote the import half of this code to look into it.

I am not super familiar with this driver either so I may have
overlooked this. Using dev->dev_private was to make sure that the
imported buffers would be mapped contiguously in the device's address
space, so I am not sure whether we need to do something in the case of
export.

Added CK and Tomasz who may have a more informed opinion on this.