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 10:11:09 +1000
From:   Dave Airlie <airlied@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexandre Courbot <acourbot@...omium.org>
Cc:     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

> 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've looked at the other results and it all seems fine to me.

Dave.