Re: [RFCv2] mac80211: Don't let regulatory make us deaf

From: Johannes Berg <johannes@sipsolutions.net>
To: Paul Stewart <pstew@chromium.org>
Cc: Jouni Malinen <j@w1.fi>,
	linux-wireless@vger.kernel.org,
	Rajkumar Manoharan <rmanohar@qca.qualcomm.com>,
	Arik Nemtsov <anamtsov@gmail.com>,
	Eliad Peller <eliad@wizery.com>
Subject: Re: [RFCv2] mac80211: Don't let regulatory make us deaf
Date: Wed, 07 Mar 2012 08:36:14 +0100	[thread overview]
Message-ID: <1331105774.3519.1.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <CAMcMvshUH5faQ7xZTkXgWE=v-WMShBa9dOPZ=nu3hYiGJvoeFA@mail.gmail.com> (sfid-20120307_064721_296874_2D6C4AB2)

On Tue, 2012-03-06 at 21:46 -0800, Paul Stewart wrote:

> >> Of course, if this we actually happen to come across a device that needs
> >> this it could set a flag somehwere and mac80211 could re-configure the
> >> channel to non-HT on the assoc request, but right now I'd rather not
> >> worry about that since we're moving towards multi-channel and have no
> >> indication of such devices existing. Agree?
> >
> > Yeah, that works for me.
> 
> Discussions seem to have come to an end here, however I'm not sure
> what we ended up deciding. :-)  I see mention of HT+TKIP -- not sure
> I'm familiar enough with what the issues are there -- as well as
> pushing the channel configuration earlier and perhaps changes to the
> association process.  Since I may not have a complete handle on all
> these adjacent issues, where do we want to go with the current change
> (fixes a real-life issue) and how do we want to stage that with
> respect to the other issues this seems to have brought to the surface?

This discussion really side-tracked somewhat -- we were discussing a
better/different solution. I'm OK with your patch, but since I'll be
touching the code again to address the other things we talked about it'd
be great if you could test after that again, maybe in a week or two?

johannes