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. > 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
