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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 23 Jul 2020 09:34:40 -0400
From:   Alex Deucher <alexdeucher@...il.com>
To:     Daniel Vetter <daniel@...ll.ch>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Dave Airlie <airlied@...ux.ie>,
        DRI <dri-devel@...ts.freedesktop.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: manual merge of the amdgpu tree with Linus' tree

On Thu, Jul 23, 2020 at 4:01 AM Daniel Vetter <daniel@...ll.ch> wrote:
>
> On Wed, Jul 22, 2020 at 6:34 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > Hi all,
> >
> > [I can't find a previous email about this, sorry ...]
> >
> > There is a semantic conflict between Linus' tree and the amdgpu tree
> > between commit
> >
> >   d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
> >
> > from Linus' tree and commts
> >
> >   fe098a5d6443 ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
> >   836dab851903 ("drm/amdgpu/atomfirmware: update vram info handling for renoir")
> >
> > The automted git merge leaves two "case 12" labels.  I have been
> > reverting commit d7a6634a4cfb since July 3 ... This will need to be
> > fixed up when the amdgpu tree is next merged into the drm tree, or a back
> > merge of d7a6634a4cfb could be done into the amdgpu tree and the older
> > "case 12" label removed in that merge.
>
> Yeah this is a bit nasty, I just crashed over it too (btw moved to
> drm-next now). Alex is this the right conflict resolution for -next? I
> think we should bake this in with a backmerge ...

Yes, you can drop either d7a6634a4cfb or fe098a5d6443.  I just
cherry-picked the commit from -next back to 5.8 and stable since it
was a bug fix.

Alex

> -Daniel
>
> >
> > --
> > Cheers,
> > Stephen Rothwell
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@...ts.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ