duplicated patch on drm-intel-nightly

duplicated patch on drm-intel-nightly

[Rodrigo Vivi]

Hi all,

We have a duplicated patch on drm-intel-nightly

commits d7006964d and cc1de6e80q

causing:

drivers/gpu/drm//amd/amdgpu/amdgpu_ttm.c:818:6: error: redefinition of
‘amdgpu_ttm_tt_affect_userptr’
 bool amdgpu_ttm_tt_affect_userptr(struct ttm_tt *ttm, unsigned long start,
      ^
drivers/gpu/drm//amd/amdgpu/amdgpu_ttm.c:799:6: note: previous
definition of ‘amdgpu_ttm_tt_affect_userptr’ was here
 bool amdgpu_ttm_tt_affect_userptr(struct ttm_tt *ttm, unsigned long start,

One cc'ed stable and other didn't. So I'm not sure how this
duplication happened or in which tree, so I'm pinging you all that
know better how to identify and solve this issue.

thanks,
Rodrigo.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: duplicated patch on drm-intel-nightly

[Jani Nikula]

On Sat, 20 Feb 2016, Rodrigo Vivi <rodrigo.vivi@gmail.com> wrote:
> We have a duplicated patch on drm-intel-nightly
>
> commits d7006964d and cc1de6e80

[I snipped the extra trailing 'q' off the 2nd commit id.]

> causing:
>
> drivers/gpu/drm//amd/amdgpu/amdgpu_ttm.c:818:6: error: redefinition of
> ‘amdgpu_ttm_tt_affect_userptr’
>  bool amdgpu_ttm_tt_affect_userptr(struct ttm_tt *ttm, unsigned long start,
>       ^
> drivers/gpu/drm//amd/amdgpu/amdgpu_ttm.c:799:6: note: previous
> definition of ‘amdgpu_ttm_tt_affect_userptr’ was here
>  bool amdgpu_ttm_tt_affect_userptr(struct ttm_tt *ttm, unsigned long start,
>
> One cc'ed stable and other didn't. So I'm not sure how this
> duplication happened or in which tree, so I'm pinging you all that
> know better how to identify and solve this issue.

There's nothing unusual here. The patch was apparently first applied to
drm-next, and then cherry-picked to drm-fixes and this one is now in
Linus' master. We do this all the time in i915.

The build fail is, or rather was, in our integration tree. I thought I
had screwed up the conflict resolution [1], but turns out the fail was
in a silent conflict. The function got added twice. It's now fixed in
our tree.

Heads up Dave, I presume this will happen when drm-next gets merged to
Linus' tree in the next merge window. (Or perhaps in linux-next
already.)


BR,
Jani.

[1] http://mid.gmane.org/87ziuwvj0o.fsf@intel.com

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel