On Wed, 2009-06-03 at 17:52 +0300, Paulius Zaleckas wrote: > Dan Williams wrote: > > On Wed, 2009-06-03 at 15:03 +0300, Paulius Zaleckas wrote: > >> Hi all, > >> > >> Currently WiMAX op_nap_scan supports scanning for NAP only > >> by NAP channel info. Fujitsu devices also supports scanning > >> by Mobile WiMAX RF profiles and also can scan whole supported > >> frequency ranges. Actually later version of Fujitsu chip does > >> not support scanning by a single frequency! > > > > Since the stack was developed against a single implementation (nobody > > else was developing Linux drivers or stuff at the time) the current > > stack reflects the best guesses of the Intel guys about what other > > hardware can do. So it's not surprising that stuff would need to be > > extended later. Scanning was specifically part of the API that was > > *under* specified because nobody was quite sure what other chips could > > do. > > > >> It is not a problem for me to add something like op_nap_scan_all > >> and op_nap_scan_rf_profiles. However there are some open questions: > > > > I was pretty sure the Intel parts could do a "wide" scan, scanning all > > frequencies they supported too. Or something like that. > > > >> 1. IMO it would be better/cleaner to not define functions just > >> returning -EOPNOTSUPP in driver. WiMAX core could just check if > >> function is not defined and return -EOPNOTSUPP ? > >> This should also make it easier to add more functions later, > >> since you won't have to update all drivers. > >> > >> 2. Connection manager needs to know which scanning methods are > >> supported (instead of calling each and checking if it returns > >> -EOPNOTSUPP). Should we extend capability flags? > > > > Yes. Connection managers need some way of figuring out what > > capabilities hardware supports so they can make intelligent decisions > > about what to do. Lets be careful about adding too many scan methods > > though... > > > > For example, if you can scan an RF profile, how is the connection > > manager supposed to figure out *which* RF profiles the card supports, so > > that it can tell the card to scan a particular RF profile based on what > > country the user is in, for example? In the end that's basically > > frequency ranges anyway. > > > > So maybe just allowing scans based on frequency ranges would be easier? > > The connection manager is easier to update, and more frequently updated, > > and thus it might make sense to put the logic of RF profiles in the > > connection manager (or the wimax network service) and have it translate > > profile -> frequency range, instead of encoding the logic about RF > > profiles in the user <-> kernel ABI. > > In Fujitsu case, the older chipset was capable to scan specific > frequencies, but new one can do only "wide" scan or scan by RF profiles. > So it looks like we will have to do scan by profiles.
BTW, maybe I missed it, but are the Fujitsu drivers open-source, or might they become open-source at some point? Dan > > Not sure, thoughts? Experience has shown that stuff like RF profiles > > and frequency ranges tend to grow over time, become re-specified and > > changed pretty frequently, and get quite complicated 3 years down the > > road. Even with licensed spectrum. > > > >> 3. I guess we will need to implement netlink interface for > >> connection manager to get supported frequencies, FFT sizes, > >> bandwidths, RF profiles and etc. Do you agree? > > > > Yes. If the connection manager can't figure out the capabilities of the > > device, it can't make intelligent decisions about the device, and it > > can't make things easier for the user. I for one really want to be able > > to get supported frequencies out of the device. If I'm a connection > > manager, and I know the user is in Europe, I don't want to even try > > scanning on 2.6 GHz. But unless the card exposes what frequencies it > > supports, I either have to (a) hardcode VID/PID/driver <-> frequency > > ranges, or (b) risk regulatory problems/take a long time to scan. > > > > Dan _______________________________________________ wimax mailing list [email protected] http://lists.linuxwimax.org/listinfo/wimax
