All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Eliad Peller <eliad@wizery.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC 2/2] mac80211: config hw when going back on-channel
Date: Mon, 25 Jul 2011 21:39:13 -0700	[thread overview]
Message-ID: <4E2E44F1.7040405@candelatech.com> (raw)
In-Reply-To: <CAB3XZEdR+oT1AFW6qN88or9XG5DFazN_BgJREC77MnroEkHBcQ@mail.gmail.com>

On 07/25/2011 01:07 PM, Eliad Peller wrote:
> On Mon, Jul 25, 2011 at 10:56 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 07/25/2011 12:16 PM, Eliad Peller wrote:
>>>
>>> hi Ben,
>>>
>>> On Mon, Jul 25, 2011 at 8:18 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>
>>>> On 07/25/2011 08:29 AM, Eliad Peller wrote:
>>>>>
>>>>> The hw is currently not configured when going
>>>>> back on-channel.
>>>>
>>>> I am less sure about this patch.  With the existing code,
>>>> I think it should catch going from on channel to off
>>>> and do the hw config properly.
>>>>
>>> IIUC, this code is responsible for going back on-channel (if there is
>>> no started work on the tmp_channel).
>>>
>>>> With your change it will also reconfig the hardware, but it will
>>>> reconfig even if we were already on-channel (if, for instance,
>>>> local->tmp_channel is oper-channel), right?
>>>>
>>>> Can you please explain in more detail how this code is
>>>> broken?
>>>>
>>> we should reconfigure the hardware iff the hardware is not configured
>>> to the operational channel.
>>> the current code doesn't handle it (e.g. oper_channel=1,
>>> tmp_channel=11, hw_channel=11. since
>>> ieee80211_cfg_on_oper_channel(local) == 0, the hw won't go back
>>> on-channel).
>>
>> If we are off-channel when entering that block of code, then tmp_channel
>> != NULL, and on_oper_chan will be false.
>>
> right.
>
>> Then, we set tmp_channel to NULL, which should make
>> ieee80211_cfg_on_oper_channel
>> true.
>>
> tmp_channel is NULL, but ieee80211_cfg_on_oper_channel() also checks for:
>
> 	/* Check current hardware-config against oper_channel. */
> 	if ((local->oper_channel != local->hw.conf.channel) ||
> 	    (local->_oper_channel_type != local->hw.conf.channel_type))
> 		return false;
>
>
> so it will return false, and hw_config won't happen.

Ahh, ok, I see your point.

Your fix should be more correct than the current code, but
I think it might still could cause hardware config when not needed.
That isn't really a bug, just less efficient.  And, I'd have to
look at the code in detail to be certain.  I'm trying to be on
vacation this week, but will poke at it when I get a chance.

In the meantime, your patch is probably worth applying, and
should probably go to stable.  Hopefully Johannes can review
it as well, as I obviously didn't get it all right the first time!

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2011-07-26  4:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 15:29 [RFC 0/2] mac80211 offchannel fixes Eliad Peller
2011-07-25 15:29 ` [RFC 1/2] mac80211: fix remain_off_channel regression Eliad Peller
2011-07-25 17:13   ` Ben Greear
2011-08-09 12:13   ` Johannes Berg
2011-08-09 12:48     ` Eliad Peller
2011-08-09 12:55       ` Johannes Berg
2011-10-19 18:03   ` Ben Greear
2011-10-20 16:47     ` Eliad Peller
2011-07-25 15:29 ` [RFC 2/2] mac80211: config hw when going back on-channel Eliad Peller
2011-07-25 17:18   ` Ben Greear
2011-07-25 19:16     ` Eliad Peller
2011-07-25 19:56       ` Ben Greear
2011-07-25 20:07         ` Eliad Peller
2011-07-26  4:39           ` Ben Greear [this message]
2011-07-26  5:48             ` Eliad Peller
2011-08-09 12:14     ` Johannes Berg
2011-08-09 13:27       ` Ben Greear
2011-08-09 13:28         ` Johannes Berg
2011-08-09 13:33           ` 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=4E2E44F1.7040405@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=eliad@wizery.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.