From: "Luis R. Rodriguez" <[email protected]>
Turns out that standard Linux distributions leave CONFIG_EXPERT
enabled. This makes this option useless for wireless testing / research
purposes as we don't want certain features enabled on all kernel
builds. This adds a new CONFIG_CFG80211_EXPERT and makes a few
features depend on them.
Luis R. Rodriguez (3):
cfg80211: add CONFIG_CFG80211_EXPERT
ath5k: replace modparam_all_channels with CONFIG_ATH5K_TEST_CHANNELS
ath9k: make CONFIG_ATH9K_DFS_CERTIFIED depend on
CONFIG_CFG80211_EXPERT
drivers/net/wireless/ath/ath5k/Kconfig | 8 ++++++++
drivers/net/wireless/ath/ath5k/base.c | 17 ++++++++++-------
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
net/wireless/Kconfig | 9 +++++++++
4 files changed, 28 insertions(+), 8 deletions(-)
--
1.7.10.rc1.22.gf5241
On Sat, Jun 16, 2012 at 02:13:59PM +0200, Arend van Spriel wrote:
> On 06/15/2012 06:53 PM, Luis R. Rodriguez wrote:
> > So how about CONFIG_CFG80211_CERTIFICATION_ONUS which can be defined
> > as an option for features / options whereby the onus for regulatory
> > certification is being accepted by the option enabler? Pretty simple
> > and to the point, and would allow for research code but also code
> > whereby a bit more work is required on the enabler like DFS
> > certification.
>
> English is not my native language so I had to look up the meaning of the
> word 'onus'. I guess I am fine with it.
Great, I'll respin.
> Apart from the naming I addressed that if would be better to have it
> device on CONFIG_WLAN instead of CFG80211 as it will be used to enable
> 802.11 device driver features. Any thoughts on that?
OK so we have CONFIG_WLAN for devices and CONFIG_WIRELESS for the subsystem
which is enabled if anyone enables CONFIG_WLAN. The kconfig entry will not only
be used for 802.11 device drivers, it will also be used for some generic
subsystem options, I'll send patches for an idea there later after the first
slew go in.
Luis
On 06/09/2012 09:55 AM, Johannes Berg wrote:
> On Fri, 2012-06-08 at 17:51 -0700, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <[email protected]>
>>
>> Turns out that standard Linux distributions leave CONFIG_EXPERT
>> enabled. This makes this option useless for wireless testing / research
>> purposes as we don't want certain features enabled on all kernel
>> builds. This adds a new CONFIG_CFG80211_EXPERT and makes a few
>> features depend on them.
>
> I'm not sure I see the point in CFG80211_EXPERT. All the features you're
> putting in there have nothing to do with cfg80211 at all anyway.
My understanding of this is that CFG80211_EXPERT was chosen because
cfg80211 provides the kernel side of the regulatory framework.
Gr. AvS
On Fri, Jun 15, 2012 at 9:09 AM, Kalle Valo <[email protected]> wrote:
> On 06/15/2012 02:06 PM, Arend van Spriel wrote:
>> On 06/15/2012 10:21 AM, Kalle Valo wrote:
>>> On 06/15/2012 11:16 AM, Johannes Berg wrote:
>>>>> As for a name, I thought about it for a while and given that we have different
>>>>>> "wireless" technologies -- bluetooth, NFC, naming this CONFIG_WIRELESS_EXPERT
>>>>>> seemed odd, and given that our 802.11 framework is under cfg80211 naming it
>>>>>> CONFIG_CFG80211_EXPERT seemed appropriate. But even if its under cfg80211
>>>>>> perhaps something more explicit about the implications may be better, how
>>>>>> about CONFIG_CFG80211_MAY_BREAK_CERTIFICATION ?
>>>>
>>>> Or you could just be explicit about it and call it
>>>> CONFIG_WIRELESS_REGULATORY_BREAKAGE or something like that :-)
>>>
>>> CONFIG_WIRELESS_CERTIFIED?
>>
>> That one looks familiar ;-)
>
> Sorry, did you suggest that already? I missed that. I guess I need to
> start organising my email better :)
We have CONFIG_ATH9K_DFS_CERTIFIED. I like something like
CONFIG_CFG80211_MAY_BREAK_CERTIFICATION given that
CONFIG_WIRELESS_CERTIFIED only assumes the kconfig options it would
depend on are all neatly developed but they could be still under
development. The only thing about
CONFIG_CFG80211_MAY_BREAK_CERTIFICATION is I suspect not many folks
would be willing to ship with that enabled at all even *after* they do
their homework.
So how about CONFIG_CFG80211_CERTIFICATION_ONUS which can be defined
as an option for features / options whereby the onus for regulatory
certification is being accepted by the option enabler? Pretty simple
and to the point, and would allow for research code but also code
whereby a bit more work is required on the enabler like DFS
certification.
Luis
On 06/15/2012 11:16 AM, Johannes Berg wrote:
>> As for a name, I thought about it for a while and given that we have different
>> > "wireless" technologies -- bluetooth, NFC, naming this CONFIG_WIRELESS_EXPERT
>> > seemed odd, and given that our 802.11 framework is under cfg80211 naming it
>> > CONFIG_CFG80211_EXPERT seemed appropriate. But even if its under cfg80211
>> > perhaps something more explicit about the implications may be better, how
>> > about CONFIG_CFG80211_MAY_BREAK_CERTIFICATION ?
>
> Or you could just be explicit about it and call it
> CONFIG_WIRELESS_REGULATORY_BREAKAGE or something like that :-)
CONFIG_WIRELESS_CERTIFIED?
Kalle
On 06/15/2012 10:21 AM, Kalle Valo wrote:
> On 06/15/2012 11:16 AM, Johannes Berg wrote:
>>> As for a name, I thought about it for a while and given that we have different
>>>> "wireless" technologies -- bluetooth, NFC, naming this CONFIG_WIRELESS_EXPERT
>>>> seemed odd, and given that our 802.11 framework is under cfg80211 naming it
>>>> CONFIG_CFG80211_EXPERT seemed appropriate. But even if its under cfg80211
>>>> perhaps something more explicit about the implications may be better, how
>>>> about CONFIG_CFG80211_MAY_BREAK_CERTIFICATION ?
>>
>> Or you could just be explicit about it and call it
>> CONFIG_WIRELESS_REGULATORY_BREAKAGE or something like that :-)
>
> CONFIG_WIRELESS_CERTIFIED?
>
> Kalle
>
Kalle,
That one looks familiar ;-) Although that name makes sense for a feature
like DFS, I think the intended use is also to hide features from unaware
users that will definitely violate with regulatory requirements.
Luis,
Is this flag purely intended for 802.11 device drivers or can it also be
used to hide certain features in stack (ie. cfg80211 or mac80211). If it
is only for device drivers I would suggest to have it depend on
CONFIG_WLAN. Suggestion for the config option:
CONFIG_WLAN_CERTIFIED_OR_SCIENTIFIC_USE
Gr. AvS
On Fri, 2012-06-08 at 17:51 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <[email protected]>
>
> Turns out that standard Linux distributions leave CONFIG_EXPERT
> enabled. This makes this option useless for wireless testing / research
> purposes as we don't want certain features enabled on all kernel
> builds. This adds a new CONFIG_CFG80211_EXPERT and makes a few
> features depend on them.
I'm not sure I see the point in CFG80211_EXPERT. All the features you're
putting in there have nothing to do with cfg80211 at all anyway.
johannes
On Mon, 2012-06-11 at 17:40 +0300, Kalle Valo wrote:
> > I still don't see the need. What would you put under it in
> > brcm[sf]mac? I certainly wouldn't see any reason to put anything
> > under it in our driver since it's much simpler to .
>
> Looks like something is missing here?
Sorry, yeah, Iwas going to say it's simpler to put something under the
driver's Kconfig.
> > Also, the argument about distros doesn't really work that way, if
> > there are users interested in something then the distros will
> > certainly enable this (CFG80211_EXPERT) option to get something
> > hidden behind it.
>
> I would compare this with NL80211_TESTMODE, we don't want distributions
> to enable that either. Of course nothing prevents distros to enable
> CFG80211_EXPERT but we need to be active to make sure it's not enabled
> (ie. check the distro configs and file bugs etc).
Right, but that's actually a feature. I see little value in a pretty
much meaningless "EXPERT wireless" Kconfig symbol that only groups
others. If, as Arend suggested, it actually has some meaning, then it
may make more sense.
johannes
On Mon, Jun 11, 2012 at 04:45:44PM +0200, Johannes Berg wrote:
> On Mon, 2012-06-11 at 17:40 +0300, Kalle Valo wrote:
>
> > > I still don't see the need. What would you put under it in
> > > brcm[sf]mac? I certainly wouldn't see any reason to put anything
> > > under it in our driver since it's much simpler to .
> >
> > Looks like something is missing here?
>
> Sorry, yeah, Iwas going to say it's simpler to put something under the
> driver's Kconfig.
>
> > > Also, the argument about distros doesn't really work that way, if
> > > there are users interested in something then the distros will
> > > certainly enable this (CFG80211_EXPERT) option to get something
> > > hidden behind it.
> >
> > I would compare this with NL80211_TESTMODE, we don't want distributions
> > to enable that either. Of course nothing prevents distros to enable
> > CFG80211_EXPERT but we need to be active to make sure it's not enabled
> > (ie. check the distro configs and file bugs etc).
>
> Right, but that's actually a feature. I see little value in a pretty
> much meaningless "EXPERT wireless" Kconfig symbol that only groups
> others. If, as Arend suggested, it actually has some meaning, then it
> may make more sense.
This option should really be used by OEM/ODM that have assured proper
certification or scientists using a shielded room. Distros should be strongly
adviced not to use this as their users tend to be unaware or the distribution
ODM / OEM may not have done the necessary work to ensure proper regulatory
certification. Perhaps we can clarify that there is a heavier onus on
regulatory certification if these options are enabled. Linux distributions may
be eager to please their users, but I would expect them to have common sense as
well. We would just have to educate them about this option.
As for a name, I thought about it for a while and given that we have different
"wireless" technologies -- bluetooth, NFC, naming this CONFIG_WIRELESS_EXPERT
seemed odd, and given that our 802.11 framework is under cfg80211 naming it
CONFIG_CFG80211_EXPERT seemed appropriate. But even if its under cfg80211
perhaps something more explicit about the implications may be better, how
about CONFIG_CFG80211_MAY_BREAK_CERTIFICATION ?
Luis
On 06/15/2012 02:06 PM, Arend van Spriel wrote:
> On 06/15/2012 10:21 AM, Kalle Valo wrote:
>> On 06/15/2012 11:16 AM, Johannes Berg wrote:
>>>> As for a name, I thought about it for a while and given that we have different
>>>>> "wireless" technologies -- bluetooth, NFC, naming this CONFIG_WIRELESS_EXPERT
>>>>> seemed odd, and given that our 802.11 framework is under cfg80211 naming it
>>>>> CONFIG_CFG80211_EXPERT seemed appropriate. But even if its under cfg80211
>>>>> perhaps something more explicit about the implications may be better, how
>>>>> about CONFIG_CFG80211_MAY_BREAK_CERTIFICATION ?
>>>
>>> Or you could just be explicit about it and call it
>>> CONFIG_WIRELESS_REGULATORY_BREAKAGE or something like that :-)
>>
>> CONFIG_WIRELESS_CERTIFIED?
>
> That one looks familiar ;-)
Sorry, did you suggest that already? I missed that. I guess I need to
start organising my email better :)
Kalle
From: "Luis R. Rodriguez" <[email protected]>
Turns out every most standard Linux distributions enable
CONFIG_EXPERT, so use the shiny new CONFIG_CFG80211_EXPERT
which is meant by design to not be enabled by all Linux
distributions.
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index e507e78..83463ed 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -64,7 +64,7 @@ config ATH9K_DEBUGFS
config ATH9K_DFS_CERTIFIED
bool "Atheros DFS support for certified platforms"
- depends on ATH9K && EXPERT
+ depends on ATH9K && CFG80211_EXPERT
default n
---help---
This option enables DFS support for initiating radiation on
--
1.7.10.rc1.22.gf5241
From: "Luis R. Rodriguez" <[email protected]>
This adds CONFIG_CFG80211_EXPERT which can be used for
non-standard settings that are typically used for device
certification testing or research purposes. We'd use
CONFIG_EXPERT alone but it seems that most standard Linux
distributions are enabling CONFIG_EXPERT already. This
allows us to define wireless specific kernel features
under a flag that is intended by design to be disabled by
standard Linux distributions.
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
net/wireless/Kconfig | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 4d2b1ec..3cc5293 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -74,6 +74,15 @@ config CFG80211_REG_DEBUG
If unsure, say N.
+config CFG80211_EXPERT
+ bool "cfg80211 expert mode"
+ depends on CFG80211 && EXPERT
+ default n
+ ---help---
+ You should disable this unless you are doing some wireless
+ certification testing in a controlled environment or working with
+ wireless research in a controlled environment.
+
config CFG80211_DEFAULT_PS
bool "enable powersave by default"
depends on CFG80211
--
1.7.10.rc1.22.gf5241
On Thu, 2012-06-14 at 12:31 -0700, Luis R. Rodriguez wrote:
> This option should really be used by OEM/ODM that have assured proper
> certification or scientists using a shielded room. Distros should be strongly
> adviced not to use this as their users tend to be unaware or the distribution
> ODM / OEM may not have done the necessary work to ensure proper regulatory
> certification. Perhaps we can clarify that there is a heavier onus on
> regulatory certification if these options are enabled. Linux distributions may
> be eager to please their users, but I would expect them to have common sense as
> well. We would just have to educate them about this option.
Yet nothing in the name of the option says so... You vaguely described
it in the Kconfig help text but that text feels like weaselling your way
out :-)
> As for a name, I thought about it for a while and given that we have different
> "wireless" technologies -- bluetooth, NFC, naming this CONFIG_WIRELESS_EXPERT
> seemed odd, and given that our 802.11 framework is under cfg80211 naming it
> CONFIG_CFG80211_EXPERT seemed appropriate. But even if its under cfg80211
> perhaps something more explicit about the implications may be better, how
> about CONFIG_CFG80211_MAY_BREAK_CERTIFICATION ?
Or you could just be explicit about it and call it
CONFIG_WIRELESS_REGULATORY_BREAKAGE or something like that :-)
johannes
On Sat, 2012-06-09 at 21:51 +0200, Arend van Spriel wrote:
> On 06/09/2012 09:55 AM, Johannes Berg wrote:
> > On Fri, 2012-06-08 at 17:51 -0700, Luis R. Rodriguez wrote:
> >> From: "Luis R. Rodriguez" <[email protected]>
> >>
> >> Turns out that standard Linux distributions leave CONFIG_EXPERT
> >> enabled. This makes this option useless for wireless testing / research
> >> purposes as we don't want certain features enabled on all kernel
> >> builds. This adds a new CONFIG_CFG80211_EXPERT and makes a few
> >> features depend on them.
> >
> > I'm not sure I see the point in CFG80211_EXPERT. All the features you're
> > putting in there have nothing to do with cfg80211 at all anyway.
>
> My understanding of this is that CFG80211_EXPERT was chosen because
> cfg80211 provides the kernel side of the regulatory framework.
It just happens though that the two options are related to regulatory --
maybe then this should have a different name? I still don't see the
need. What would you put under it in brcm[sf]mac? I certainly wouldn't
see any reason to put anything under it in our driver since it's much
simpler to .
Also, the argument about distros doesn't really work that way, if there
are users interested in something then the distros will certainly enable
this (CFG80211_EXPERT) option to get something hidden behind it.
johannes
On 06/15/2012 06:53 PM, Luis R. Rodriguez wrote:
> So how about CONFIG_CFG80211_CERTIFICATION_ONUS which can be defined
> as an option for features / options whereby the onus for regulatory
> certification is being accepted by the option enabler? Pretty simple
> and to the point, and would allow for research code but also code
> whereby a bit more work is required on the enabler like DFS
> certification.
English is not my native language so I had to look up the meaning of the
word 'onus'. I guess I am fine with it.
Apart from the naming I addressed that if would be better to have it
device on CONFIG_WLAN instead of CFG80211 as it will be used to enable
802.11 device driver features. Any thoughts on that?
Gr. AvS
From: "Luis R. Rodriguez" <[email protected]>
This stashes away this feature from standard kernel builds.
Signed-off-by: Luis R. Rodriguez <[email protected]>
---
drivers/net/wireless/ath/ath5k/Kconfig | 8 ++++++++
drivers/net/wireless/ath/ath5k/base.c | 17 ++++++++++-------
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index e18a9aa..631d336 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -64,3 +64,11 @@ config ATH5K_PCI
---help---
This adds support for PCI type chipsets of the 5xxx Atheros
family.
+
+config ATH5K_TEST_CHANNELS
+ bool "Enables testing channels on ath5k"
+ depends on ATH5K && CFG80211_EXPERT
+ ---help---
+ This enables non-standard IEEE 802.11 channels on ath5k, which
+ can be used for research purposes. This option should be disabled
+ unless doing research.
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index fbaa309..96739a9 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -74,10 +74,6 @@ bool ath5k_modparam_nohwcrypt;
module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
-static bool modparam_all_channels;
-module_param_named(all_channels, modparam_all_channels, bool, S_IRUGO);
-MODULE_PARM_DESC(all_channels, "Expose all channels the device can use.");
-
static bool modparam_fastchanswitch;
module_param_named(fastchanswitch, modparam_fastchanswitch, bool, S_IRUGO);
MODULE_PARM_DESC(fastchanswitch, "Enable fast channel switching for AR2413/AR5413 radios.");
@@ -258,8 +254,15 @@ static int ath5k_reg_notifier(struct wiphy *wiphy, struct regulatory_request *re
\********************/
/*
- * Returns true for the channel numbers used without all_channels modparam.
+ * Returns true for the channel numbers used.
*/
+#ifdef CONFIG_ATH5K_TEST_CHANNELS
+static bool ath5k_is_standard_channel(short chan, enum ieee80211_band band)
+{
+ return true;
+}
+
+#else
static bool ath5k_is_standard_channel(short chan, enum ieee80211_band band)
{
if (band == IEEE80211_BAND_2GHZ && chan <= 14)
@@ -276,6 +279,7 @@ static bool ath5k_is_standard_channel(short chan, enum ieee80211_band band)
/* 802.11j 4.9GHz (20MHz) */
(chan == 184 || chan == 188 || chan == 192 || chan == 196));
}
+#endif
static unsigned int
ath5k_setup_channels(struct ath5k_hw *ah, struct ieee80211_channel *channels,
@@ -316,8 +320,7 @@ ath5k_setup_channels(struct ath5k_hw *ah, struct ieee80211_channel *channels,
if (!ath5k_channel_ok(ah, &channels[count]))
continue;
- if (!modparam_all_channels &&
- !ath5k_is_standard_channel(ch, band))
+ if (!ath5k_is_standard_channel(ch, band))
continue;
count++;
--
1.7.10.rc1.22.gf5241
On 06/11/2012 10:32 AM, Johannes Berg wrote:
> On Sat, 2012-06-09 at 21:51 +0200, Arend van Spriel wrote:
>> On 06/09/2012 09:55 AM, Johannes Berg wrote:
>>> On Fri, 2012-06-08 at 17:51 -0700, Luis R. Rodriguez wrote:
>>>> From: "Luis R. Rodriguez" <[email protected]>
>>>>
>>>> Turns out that standard Linux distributions leave
>>>> CONFIG_EXPERT enabled. This makes this option useless for
>>>> wireless testing / research purposes as we don't want certain
>>>> features enabled on all kernel builds. This adds a new
>>>> CONFIG_CFG80211_EXPERT and makes a few features depend on
>>>> them.
>>>
>>> I'm not sure I see the point in CFG80211_EXPERT. All the features
>>> you're putting in there have nothing to do with cfg80211 at all
>>> anyway.
>>
>> My understanding of this is that CFG80211_EXPERT was chosen
>> because cfg80211 provides the kernel side of the regulatory
>> framework.
>
> It just happens though that the two options are related to regulatory
> -- maybe then this should have a different name?
It could be more than that, for example we could also add nl80211
testmode under CFG80211_EXPERT.
> I still don't see the need. What would you put under it in
> brcm[sf]mac? I certainly wouldn't see any reason to put anything
> under it in our driver since it's much simpler to .
Looks like something is missing here?
> Also, the argument about distros doesn't really work that way, if
> there are users interested in something then the distros will
> certainly enable this (CFG80211_EXPERT) option to get something
> hidden behind it.
I would compare this with NL80211_TESTMODE, we don't want distributions
to enable that either. Of course nothing prevents distros to enable
CFG80211_EXPERT but we need to be active to make sure it's not enabled
(ie. check the distro configs and file bugs etc).
Kalle
On 06/11/2012 05:45 PM, Johannes Berg wrote:
> On Mon, 2012-06-11 at 17:40 +0300, Kalle Valo wrote:
>
>> I would compare this with NL80211_TESTMODE, we don't want distributions
>> to enable that either. Of course nothing prevents distros to enable
>> CFG80211_EXPERT but we need to be active to make sure it's not enabled
>> (ie. check the distro configs and file bugs etc).
>
> Right, but that's actually a feature. I see little value in a pretty
> much meaningless "EXPERT wireless" Kconfig symbol that only groups
> others.
Ah, I see.
> If, as Arend suggested, it actually has some meaning, then it
> may make more sense.
Yeah, I see your point.
FWIW I do see the value with CFG80211_EXPERT as it makes more difficult
for users to accidentally enable certain features. And it makes it
easier for us to search for distros which have CFG80211_EXPERT enabled.
Kalle