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

[Ian Romanick]

On 04/04/2018 11:30 AM, Mark Janes wrote:
> 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

I thought:

    NOTE: I have sent a couple tests to the piglit list that reproduce this
    bug *without* the commit mentioned below.  This commit fixes those
    tests.

made it pretty clear that this is a pre-existing bug.  The commit
mentioned in Fixes: just made it happen more.