Re: Patch "iwlwifi: mvm: handle FRAME_RELEASE in MQ code" has been added to the 4.7-stable tree

["Coelho, Luciano" <luciano.coelho@intel.com>]

On Wed, 2016-10-05 at 09:24 +0200, gregkh@linuxfoundation.org wrote:
> On Wed, Oct 05, 2016 at 07:15:41AM +0000, Coelho, Luciano wrote:
> > 
> > On Wed, 2016-10-05 at 08:47 +0200, gregkh@linuxfoundation.org wrote:
> > > 
> > > On Wed, Oct 05, 2016 at 07:38:10AM +0200, Johannes Berg wrote:
> > > > 
> > > > 
> > > > On Tue, 2016-10-04 at 16:22 +0000, gregkh@linuxfoundation.org wrote:
> > > > > 
> > > > > 
> > > > > This is a note to let you know that I've just added the patch titled
> > > > > 
> > > > >     iwlwifi: mvm: handle FRAME_RELEASE in MQ code
> > > > > 
> > > > > to the 4.7-stable tree which can be found at:
> > > > >     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue
> > > > > .git;a=summary
> > > > > 
> > > > > The filename of the patch is:
> > > > >      iwlwifi-mvm-handle-frame_release-in-mq-code.patch
> > > > > and it can be found in the queue-4.7 subdirectory.
> > > > > 
> > > > > If you, or anyone else, feels it should not be added to the stable
> > > > > tree, please let <stable@vger.kernel.org> know about it.
> > > > 
> > > > I have no particular objections to including this, but it only fixes
> > > > something for (unreleased) hardware that will likely never work on the
> > > > 4.7 kernel (due to also unreleased firmware, and likelihood of never
> > > > releasing older firmware versions).
> > > > 
> > > > So there's almost certainly no point, but OTOH it also cannot possibly
> > > > hurt since this code path is only taken with that particular hardware.
> > > 
> > > Ok, thanks for letting me know, I've now dropped it from the stable
> > > queue.
> > 
> > Is there a way to mark the Fixes tag with the minimum kernel
> > version as we would do e.g. with "Cc: stable@vger.kernel.org #
> > 4.8+"?
> 
> The fixes tag is to show what commit it fixed.  And since you were
> fixing a patch that is in the 4.7 release, you are implying that it is
> resolving an issue for that kernel, right?

Well, what I meant is what happened in this case.  We try to keep our
upstream driver in sync with our internal trees, sometimes (again, as
in this case) when the HW is not even out yet.

Let's say the hardware in question would be supported fully only from
4.9+, but a pre-work patch is already in 4.8.  The Fixes tag *does*
point to a real commit it fixes, but it is only relevant for 4.9+...

Anyway, this is probably a very rare case.  I was just nitpicking and
thinking whether we could have prevented the (small) overhead of
getting the patch in the stable queue, getting a comment and removing
it from the queue, when we already knew from the beginning that it was
irrelevant for some kernels.

--
Cheers,
Luca.