Dan Williams wrote: > 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?
Currently there is no open source driver, but hey that is what I am currently working on! > 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
