On Fri, 2007-10-05 at 23:19 +0100, Adam Baker wrote: > I've observed an undesirable change in behaviour of rt2x00 as a result of > Johannes Berg's patch 3d4803379613c763f5a7863e8249b63d190af5e6 > (remove all prism2 ioctls). > It used to consistently default to 802.11g mode on g capable hardware. Because > that patch removed the lines > > - /* Use next_mode as the mode preference to > - * resolve non-unique channel numbers. */ > - if (set && mode->mode != local->next_mode) > - continue; > > in ieee80211_set_channel it now defaults to 11b unless I change the code that > calls ieee80211_register_hwmode. (I realise that the next_mode test is no > longer "right"). > > This is because ieee80211_set_channel will now prefer to select whichever was > the last mode for which the driver called ieee80211_register_hwmode whereas > the previous behaviour preferred the first registered mode. It seems as > though if there was a way to avoid calling Iieee80211_set_channel then the > setting of oper_hw_mode in ieee80211_register_hwmode would still prefer the > first registered mode. Yeah, you're right, it was too much to remove the whole conditional and the continue, I should've just removed the && mode stuff. Will post a patch to add it back. > Is it intended that the order of calling ieee80211_register_hwmode should > determine which mode should be preferred when multiple modes exist on the > same channel or is there either already or planned a better option for driver > writers? If calling order should determine preference should it be first or > last registered? That's actually a can of worms. Luis is working (I hope) on resolving these issues with mode vs. frequency selection. However, I'm not entirely convinced that mode selection should be done by userspace when we are acting as a client. I think we should simply exploit hardware capabilities as much as possible and then use the set that the AP advertised (or rather as much as we can support of that). Hence, for these questions it'd be good to know whether the ralink drivers do anything different based on the selected mode, and if they do (I assume they do because they register B *and* G modes) what it is. It'd probably help a lot with the design of the interface if you could answer that. I feel that mode selection should not be necessary since in G mode a device needs to have the capability to talk to B-only stations and hence must be able to "fall back" to B mode, we should therefore be able to exploit that capability without the driver ever registering different modes. In fact, I think that the driver can probably simply register the modulations/bitrates it can support orthogonally to the frequencies it supports, and the frequencies consist of only information about the frequency and possibly hardware value used to select it. This was part of what I posted a while ago when Luis was posting his regulatory stuff, and I think should be addressed while cleaning up that whole mess. Thanks, johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
