public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
	Jouni Malinen <jouni.malinen@atheros.com>
Subject: Re: [PATCH] cfg80211: fix regression on beacon world roaming feature
Date: Fri, 31 Jul 2009 09:32:57 -0700	[thread overview]
Message-ID: <43e72e890907310932u4510fc6fwc0c3dab598036041@mail.gmail.com> (raw)
In-Reply-To: <1249056713.25587.6.camel@johannes.local>

On Fri, Jul 31, 2009 at 9:11 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-31 at 09:03 -0700, Luis R. Rodriguez wrote:
>
>> > I did mean those devices. Adding a reg notifier hook for iwlwifi seems a
>> > little odd, given that cfg80211 is supposed to always honour the flags
>> > (which it copies to orig_flags for that purpose).
>> >
>> > But I don't see why ath couldn't do this:
>> >
>> >  * do _not_ set the passive/no-ibss flags in flags (orig_flags)
>>
>> That's up to cfg80211 through the custom regdomain, so yes, and in
>> fact we can WARN if these are set.
>
> Ah, that seems a little heavy-handed :)
>
>> >  * in the reg notifier, always set the passive/no-ibss flag into 'flags'
>> >   unless a beacon was noticed on that channel.
>>
>> That's fine too, we still need a fix for 2.6.31. Do you have any
>> thoughts on that?
>
> Not really, tbh. Seems like all you'd have to do is remove the
> IEEE80211_CHAN_PASSIVE_SCAN/IEEE80211_CHAN_NO_IBSS flags from your
> channel registration,

Its not that simple. Consider the fact we build our own custom
regulatory domain and stuff what is intended for each one of them. The
_orig stuff is set upon channel registration so it is correct that
we'd have to avoid setting the channel flags prior to wiphy
registration. How you do that is left up to implementation. Since
cfg80211 will set the channel *_orig params based on
wiphy_registration() you're only option is to either prevent your
wiphy being registered with the flags set or to reset the channel
flags on the reg_notifier(). The later seems like the way to go but we
currently do not call the reg_notifier() upon beacon hints -- we
currently only call the reg_notifier() upon regulatory domain changes
and upon wiphy registration. My point is both of these options require
considerable changes for 2.6.31.

> and set them in ath_reg_apply_beaconing_flags and
> ath_reg_apply_active_scan_flags, changing the polarity?
>
> I mean, right now you tell cfg80211 you don't support it,
> and then try
> to support it anyhow.

Not sure I follow, support what? The reg_notifier() is there for
regulatory domain changes, we didn't call it upon beacon hints. We
can, and I agree its the right approach, but not for 2.6.31.

> Instead, you could tell cfg80211 you _do_ support
> it, and then not support them depending on the notifier? It seems like
> that should work and not break cfg80211's assumption that you can never
> ever support _more_ than registration flags (orig_flags).

I'm not following at all, orig_flags do not tell cfg80211 the channel
flags the device supports. Most devices set flag to 0 upon wiphy
registration and therefore cfg80211 sets orig_flags to 0 as well
during wiphy registration.

  Luis

  reply	other threads:[~2009-07-31 16:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-31  0:43 [PATCH] cfg80211: fix regression on beacon world roaming feature Luis R. Rodriguez
2009-07-31  7:45 ` Johannes Berg
2009-07-31 15:49   ` Luis R. Rodriguez
2009-07-31 15:56     ` Johannes Berg
2009-07-31 16:03       ` Luis R. Rodriguez
2009-07-31 16:11         ` Johannes Berg
2009-07-31 16:32           ` Luis R. Rodriguez [this message]
2009-07-31 16:43             ` Johannes Berg
2009-07-31 17:28               ` Luis R. Rodriguez
2009-07-31 17:30                 ` Luis R. Rodriguez
2009-07-31 17:52 ` Johannes Berg
2009-07-31 17:59   ` Luis R. Rodriguez

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=43e72e890907310932u4510fc6fwc0c3dab598036041@mail.gmail.com \
    --to=lrodriguez@atheros.com \
    --cc=johannes@sipsolutions.net \
    --cc=jouni.malinen@atheros.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /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