From: Seth Forshee <seth.forshee@canonical.com>
To: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFT] iwlwifi: dvm: drop non VO frames when flushing
Date: Mon, 6 Oct 2014 07:59:21 -0500 [thread overview]
Message-ID: <20141006125921.GE131459@ubuntu-hedt> (raw)
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB31B53CC1F@hasmsx107.ger.corp.intel.com>
On Mon, Oct 06, 2014 at 12:47:41PM +0000, Grumbach, Emmanuel wrote:
> >
> > On Mon, Oct 06, 2014 at 07:43:07AM -0500, Seth Forshee wrote:
> > > On Mon, Oct 06, 2014 at 12:35:46PM +0000, Grumbach, Emmanuel wrote:
> > > > > Subject: Re: [RFT] iwlwifi: dvm: drop non VO frames when flushing
> > > > >
> > > > > On Sun, Oct 05, 2014 at 04:57:12PM +0300, Emmanuel Grumbach wrote:
> > > > > > + if (vif)
> > > > > > + scd_queues &= ~BIT(vif-
> > >hw_queue[IEEE80211_AC_VO]);
> > > > >
> > > > > I'm backporting this to 3.13, and this part doesn't work unless
> > > > > 77be2c54c5bd26279abc13807398771d80cda37a is also backported. Is
> > > > > this critical, or can it be omitted in the backport?
> > > > >
> > > >
> > > > 77be2c54c5bd26279abc13807398771d80cda37a isn't really critical, but it is
> > a dependency, and it is safe IMO.
> > > > But I'd wait for a bit more testing :) The patch isn't even in my
> > > > tree yet :)
> > >
> > > My backport is for testing too. Most of our bugs are against Ubuntu
> > > 14.04, which uses 3.13. Seems better to have them test this change in
> > > isolation rather than also testing everything which has changed up to
> > > 3.17.
> > >
> > > I agree the patch is safe,
> >
> > Sorry, I was ambiguous here. I mean that
> > 77be2c54c5bd26279abc13807398771d80cda37a is safe to backport.
> >
> > > but I'd also prefer to have it tested in the form which would
> > > eventually get applied to the 3.13 extended stable tree. So I take it
> > > for stable you would advocate applying both patches?
>
> I guess... I can rework the discussed patch (drop non VO ...) to work without
> 77be2c54c5bd26279abc13807398771d80cda37a, but is it really worth it?
> I don't see any reason not to backport 77be2c54c5bd26279abc13807398771d80cda37a.
> IMHO, the easiest is to backport 77be2c54c5bd26279abc13807398771d80cda37a and
> apply the drop non VO on top of it.
>
> What am I missing?
Nothing, except that stable kernel rules dictate that only bug fixes
will be applied. 77be2c54c5 isn't a bug fix. If it's a necessary
prerequisite then I suspect they'd be accomodating, but if it's not
necessary then they might request a backport which doesn't require
77be2c54c5.
No sense it beating it to death now though. I'll backport both, and if
the stable trees end up with something different I can ask for
additional testing. Especially if it involves more than simply dropping
those two lines.
Thanks,
Seth
next prev parent reply other threads:[~2014-10-06 12:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-05 13:57 [RFT] iwlwifi: dvm: drop non VO frames when flushing Emmanuel Grumbach
2014-10-05 15:07 ` Sujith Manoharan
2014-10-05 15:35 ` Grumbach, Emmanuel
2014-10-05 15:43 ` Sujith Manoharan
2014-10-05 16:53 ` Seth Forshee
2014-10-06 12:33 ` Seth Forshee
2014-10-06 12:35 ` Grumbach, Emmanuel
2014-10-06 12:43 ` Seth Forshee
2014-10-06 12:44 ` Seth Forshee
2014-10-06 12:47 ` Grumbach, Emmanuel
2014-10-06 12:59 ` Seth Forshee [this message]
2014-10-06 13:01 ` Grumbach, Emmanuel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141006125921.GE131459@ubuntu-hedt \
--to=seth.forshee@canonical.com \
--cc=emmanuel.grumbach@intel.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox