Inaky Perez-Gonzalez wrote: > On Wednesday 03 June 2009, 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! > > Can you elaborate more on the RF Profile thingie (as in how do they define > exactly)? The whole supported freq ranges could be defined as a case of scan > specific frequencies (actually, the other way around), so I am not too > worried about it for now :)
RF profiles as Fujitsu device understands them are defined in "WiMAX Forum Mobile System Profile Release 1.0" under chapter "6. Radio Profile". Besides these profiles defined be WiMAX Forum it also supports few custom profiles, but I think they are not very important... When scanning you can specify a list of profiles it will scan. These profiles define frequency range and bandwidth. >> 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 have no problem with adding more stuff, but I'd like to understand first > all > the implications, so we can make a decision that will fit everybody :) > >> 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. > > So far, all the defined functions had to be mandatory, with in some cases, it > not being supported (EOPNOTSUPP). I think these existing functions could be made optional: op_nap_scan_start (maybe we should rename it? op_nap_scan_freq_start?) op_nap_query_nsps op_nap_query_realms > However, for new entry points that are not so strict, we can do that. > >> 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? > > Sure, that's why it is there. Currently there is only one defined, the NAP > one > (with the capability WIMAX_CAP_NAP_IF), but as we come out with more stuff, > we'll add more bits to it when needed. > >> 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? > > IT should be in the latest tip, as part of CAPs. You can access it with > wimaxll_cap*(). Been there for a while. Cool. Somehow I missed this :) > Once we sort out the RF profiles, we can see how to add that information too > for devices htat need/support it. _______________________________________________ wimax mailing list [email protected] http://lists.linuxwimax.org/listinfo/wimax
