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-title47-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. >> > + * 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? >> > > 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? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
