> On Wed, Jul 10, 2013 at 3:47 AM, Peer, Ilan <ilan.peer@xxxxxxxxx> wrote: > >> Are you aware of UNII-1, UNII-2, UNII-2E, UNII-3 are specific world > >> regulatory language bands? When I last tried to look for a clear > >> definition I could not find a clear definition of them and its why on > >> the ath module on for QCA modules I state "we call these" in > >> reference to the UNII nomenclature. If we can get a clear resource for its > definition that would help here. > >> > > > > Maybe these link will help. > > http://www.gpo.gov/fdsys/pkg/CFR-2010-title47-vol1/xml/CFR-2010-title4 > > 7-vol1-part15.xml#seqnum15.403 > > http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-13-22A1.pdf > > > > Anyway, I will use your ''we call these" notation as well :) > > No no, this is good, its just United States / FCC biased and I hadn't seen the > documentation you provided before. This confirms these are official terms but > still just US / FCC biased. My point was that we should be careful to not make > global statements on regulatory code about things that are not global. If we > know only the FCC calls this UNII well lets document that and provide the > reference you supplied. I anticipated having to deal with special case > regulatory code outside of of what CRDA / wireless-regdb provides -- given that > CRDA / wireless-regdb were meant to be more RF agnostic anyway. > > Given that other vendors may also want to get the UNII band can you stuff > instead cfg80211_get_unii_band() into reg.c and do the #ifdef properly with the > Kconfig, and export it as well, as well as document it properly providing the > reference you mentioned. Sure. > > >> > + * 1. Indoor only: a GO can be operational on such a channel, iff there is > >> > + * clear assessment that the platform device is indoor. > >> > + * 2. Concurrent GO: a GO can be operational on such a channel, > >> > + iff there is > >> an > >> > + * additional station interface connected to an AP on this channel. > >> > + * > >> > + * TODO: The function is too permissive, as it does not verify the > >> > + platform > >> > + * device type is indeed indoor, or that the AP is indoor/AC powered. > >> > >> So to do this properly we need an eventual userspace API to throw to > >> kernelspace if we are AC powered? We'll need this to enhance this > >> routine here? > >> > > > > Not sure about this point. I prefer leaving the exact knowledge of the device > type, being AC Powered or not (and which type of AC power) etc. out side of the > kernel. The approach I chose with this patch was to only allow to start a GO on > such a channel, making the basic verification done above, assuming that the > user space component guarantees that all the full restrictions are satisfied. > > Fair enough. Seems we just need to zero in now on the requirement or not on > the extra flag you suggested. > > >> In the meantime, while you get all your patch sets properly developed > >> I'd recommend to define the code returning false there strictly or > >> perhaps for any flag on the channel requiring DFS / no-ibss, or > >> passive scan. The stricter case, defining false always, seems to be what you > are suggesting here. > > > > I do not think that this is needed here. Returning false, means that the code > should test if the PASSIVE_SCAN and NO_IBSS are not set on the channel we > want to start beaconing on. > > > >> Do you have a white list that can exclude some channels for now > >> globally or somehow as all this lines up? > >> > > I'll try to provide such list ... > > Note sure I understood what you are looking for. Can you please clarify this > point? > > It was unclear for what exact channels you needed to deal with here. > Given review so far wouldn't it just be DFS flagged channels on some UNII > bands ? Then again if the indoor flag needs to be pegged to to a specific UNII > band and we can do that on wireless-regdb do we even need the UNII band > check routine helper? > Generally it is possible that the indoor property is not pegged to the 'other_channel', or it is possible that it is pegged but they are not in the same UNII band, so the verification is still needed. I guess that once I get the list you requested things will be clearer :) Regards, Ilan. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
