[Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Emil Velikov <emil.l.velikov at gmail.com> writes:

> On 4 April 2018 at 17:40, Mark Janes <mark.a.janes at intel.com> wrote:
>> Leo Liu <leo.liu at amd.com> writes:
>>
>>> On the CI family, firmware requires the destory command have to be the
>>> last command in the IB, moving feedback command after destroy is causing
>>> issues on CI cards, so we have to keep the previous logic that moves
>>> destroy back to the last command.
>>>
>>> But as the original issue fixed previously, with the newer family like Vega10,
>>> feedback command have to be included inside of the task info command along
>>> with destroy command.
>>>
>>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>>>
>>> Signed-off-by: Leo Liu <leo.liu at amd.com>
>>> Cc: mesa-stable at lists.freedesktop.org
>>
>> These tags seem ambiguous to me.  If this commit fixes a specific
>> commit, then the patch should be applied only to stable branches which
>> contain that commit.
>>
>> However, the mesa-stable CC caused this patch to be applied to 17.3,
>> which does *not* contain the broken patch.
>>
>> Leo: did you intend for the mesa-stable CC to cause this patch to be
>> applied to older stable branches?
>>
>> Release managers: is there a protocol for how this specification should
>> be parsed, when considering a patch for stable?
>>
> If the Fixes tag, reference a commit that is missing in specific
> stable branch then obviously the fix is not suitable.
> Hence the stable piece than be ignored + alongside a reply to the
> patch that it will not be in $stable_branch because $reason.

OK, we have violated this policy at least a couple times in the previous
release, based on my audits:

  2f67c9b17518cf0d2fe946e39e5b8ff5ec2797c5
  i965/vec4: Fix null destination register in 3-source instructions

  6f69b63896ce2352aaa25f89287133f7f2ba1fab
  radeon/vce: move feedback command inside of destroy function

> Even if offending commit is not part of $stable_branch, getting into
> the habit and cross-referencing is very beneficial.
> Some customers may use non-stable branch, hence having track of which
> fixes they need is a smart move.
>
> HTH
> Emil