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)
johannes
--
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
