Hi, please help me understand some general practices involved in kernel development. Specifically, I'm interested in how patches are included or reverted in different kernel versions.
Let's consider a practical example, the history of patch "drm/i915/execlists: Reset RING registers upon resume" . This patch was committed 641 commits after version 4.8-rc2:
$ git describe bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
So I would expect to find it in version 4.8, which is the stable, final release of v4.8, following all the release canditates.
However, if I search for the tag that follows (and hence contains) that commit, I do not find version 4.8, nor version 4.9, but 4.10:
$ git describe --contains bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
Why? Why not v4.8-rc3? This means that the patch has been included neither in v4.8 nor in v4.9, but only in version 4.10-rc1, right? Why so much time was needed, considering it was the 621st commit on top ov v4.8-rc2?
Another thing that confuses me is the following. In fact that patch ended up in v4.9.9 . If my reasoning above is correct, it was backported from v4.10, right?
Then some problems were reported, and it was reverted in v4.9.23 with commit 0ee72d8f9b8e17b8e4ccfebc7a25cbc2d395cd6a . (What led to the decision of reverting it is explained in  and ).
So my question now is--what version contains this patch? Is it true that I find it in v4.10?
Stretch currently provides kernel version 4.9.30:
$ uname -v
#1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
Since v4.9.30 follows v4.9.23, the patch is not be included in Stretch's kernel, so this explains why I'm experiencing the bug addressed by this patch.
Thanks for your help.
⣾⠁⢠⠒⠀⣿⡁ Sent from my brain using neurons fueled by glucose.