From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Ben Greear <greearb@candelatech.com>
Cc: linux-wireless@vger.kernel.org, Eliad Peller <eliad@wizery.com>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [PATCH] mac80211: Fix off-channel problem in work task.
Date: Thu, 20 Oct 2011 18:09:00 +0200 [thread overview]
Message-ID: <20111020160859.GC2293@redhat.com> (raw)
In-Reply-To: <4EA03CCF.6090604@candelatech.com>
On Thu, Oct 20, 2011 at 08:22:55AM -0700, Ben Greear wrote:
> On 10/20/2011 07:58 AM, Stanislaw Gruszka wrote:
> >On Wed, Oct 19, 2011 at 11:44:36AM -0700, greearb@candelatech.com wrote:
> >>From: Ben Greear<greearb@candelatech.com>
> >>
> >>The ieee80211_cfg_on_oper_channel method compared the
> >>current hardware config as well as the desired hardware
> >>config. In most cases, this is proper, but when deciding
> >>whether to go back on-channel, if the hardware is not
> >>configured on-channel, but logically it *should* be
> >>on-channel, then we must go on-channel.
> >>
> >>This patch adds a flag to the ieee80211_cfg_on_oper_channel
> >>logic to disable comparing the actual hardware so we do not
> >>have to create another tricky method with similar logic.
> >>
> >>Reported-by: Eliad Peller<eliad@wizery.com>
> >>Signed-off-by: Ben Greear<greearb@candelatech.com>
> >
> >I much more prefer previous one-line patch from Eliad
> >http://news.gmane.org/find-root.php?message_id=%3c1311607763%2d12603%2d3%2dgit%2dsend%2demail%2deliad%40wizery.com%3e
> >
> >this one seems to provide unneeded code complexity, but
> >behaviour i.e. number of channel switches in hardware
> >is the same.
>
> I believe it's possible to set tmp_channel to NULL and not actually
> change the on/off channel configuration, and my patch should allow us to
> skip a hardware config in that case.
>
> However, this might only be possible if we are in this code while
> scanning, and currently, I don't believe we can be in this work
> code while scanning.
So you want to optimize a case that is not even possible at present.
Do you know that "premature optimization is the root of all evil" ? :-)
I'm not quite against by that change, but I would like to have -stable
fixes, since bug we are talking about not only annoys people by warning,
but also disallow to associate to wireless network. I prefer that we
apply Eliad patches and cc -stable and do possible further optimization
on top of that (ideally if some measurement will be available that show
optimization really works).
Thanks
Stanislaw
next prev parent reply other threads:[~2011-10-20 16:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 18:44 [PATCH] mac80211: Fix off-channel problem in work task greearb
2011-10-20 14:58 ` Stanislaw Gruszka
2011-10-20 15:22 ` Ben Greear
2011-10-20 16:09 ` Stanislaw Gruszka [this message]
2011-10-20 16:12 ` Ben Greear
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=20111020160859.GC2293@redhat.com \
--to=sgruszka@redhat.com \
--cc=eliad@wizery.com \
--cc=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--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;
as well as URLs for NNTP newsgroup(s).