On Wed, Aug 1, 2012 at 11:45 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
> On Wed, 2012-08-01 at 22:54 +0300, Arik Nemtsov wrote:
>> On Wed, Aug 1, 2012 at 10:33 PM, Johannes Berg
>> <johannes@xxxxxxxxxxxxxxxx> wrote:
>> > On Wed, 2012-08-01 at 22:28 +0300, Arik Nemtsov wrote:
>> >
>> >> > +static void
>> >> > +ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
>> >> > + u8 new_chan_no, u8 count, u8 mode,
>> >> > + enum ieee80211_band new_band,
>> >> > + struct ieee80211_bss *bss, u64 timestamp)
>> >> > {
>> >> > struct cfg80211_bss *cbss =
>> >> > container_of((void *)bss, struct cfg80211_bss, priv);
>> >> > struct ieee80211_channel *new_ch;
>> >> > struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
>> >> > - int new_freq = ieee80211_channel_to_frequency(sw_elem->new_ch_num,
>> >> > - cbss->channel->band);
>> >> > + int new_freq = ieee80211_channel_to_frequency(new_chan_no, new_band);
>> >>
>> >> I'm not sure a channel switch between bands should be allowed. Case in
>> >> point - a device might have different HT capabilities between bands,
>> >> so different rates might need to be programmed to FW. This would
>> >> require a re-assoc..
>> >
>> > Hmm, that might require some new flags or something? I'm not even sure
>> > the extended chanswitch is allowed to switch bands, but by the look of
>> > it that must have been the intent?
>>
>> Maybe the idea was to change the operating class while staying in the
>> same band? But now I'm thinking that even without different HT caps
>> per band, the change of class alone might impose new regulatory
>> restrictions. For instance HT40 may now be allowed/disallowed.
>> So we have to notify the driver about this somehow?
>>
>> If it's too cumbersome, maybe we should just disconnect if the class
>> changes? wpa_s would reconnect anyway in most situations (non p2p).
>
> Yeah, maybe. I'm just going to drop patches 6 and 7 for now. The
> extended switch handling was just something I thought about, not
> actually necessary for what I'm doing (still multi-channel work)
Sounds good.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
