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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.