> > 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. The only difference currently in rt2x00 is for rt2500usb. The initialization of the IFS and EIFS register is different. I haven't gone through the legacy driver to see if there aren't any further changes. But since I believe I have extracted all register initializations that meant something from the legacy driver, this small difference can probably be considered as the only thing. > 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. And is mac80211 doing that correctly at this time? If so I could drop the 802.11B mode registration if that is the preferred action. > 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. Only registering the supported rates and channels and let mac80211 sort out the modes itself does sound like a good idea. :) Ivo - 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